Прктрвнье, "проектирование" и проектирование
Проектирование — это не прототип накалякать.
10.03.2015 | Автор: Александр Туник, Проектная студия «Тектоника» (Руководитель и проектировщик) 
Проектирование вошло в моду, его делают уже в каждой подворотне. Статьи по UX, UI и Usability прочитаны от хедера до футера. Хорошо? Хорошо.
Только вот называют этим словом слишком разные вещи со слишком разным результатом. Есть ощущение, что у 99% специалистов и заказчиков проектирование ограничивается ТЗ на страничку (иначе — «брифом») и прототипом. Нехорошо.
Таблица ниже показывает моё видение ситуации. Это короткое и страдающее отсутствием примеров «правильного» проектирования изложение, но всего в одной статье не скажешь.
Часть работ
прктрвнье
«проектирование»
Проектирование
Сбор и анализ информации
ТЗ от заказчика (все знаю, что это такое, да?) + 10 простых вопросов вроде «Пришлите каталог с описанием товара».
ТЗ от заказчика + аж 20 вопросов чуть посложнее.
Проработка доброй сотни вопросов о целях, требованиях, бизнесе, процессах, маркетинге, аудитории, среде. Опросы, интервью, контент-, сравнительный и поведенческий анализ, выход в поле. Выводы, наконец.
Персонажи и сценарии
«Мужчина 20–60 лет. Нужно оборудование.»
«Сергей, 25–50 лет, старший инженер, любит маму, рыбалку и природу. Поручили выбрать оборудование для снижения расходов на топливо.»
Подробное описание: стимулы, мотивы, задачи, вопросы, сомнения, барьеры, откуда и зачем придёт, какой есть опыт и знания, ожидания и критерии оценки, особенности взаимодействия… Вот небольшой кусочек описания персонажа: https://yadi.sk/i/9f4Qkr1FehfVg, специально без лица и общей информации.
Концепция
—
—
Идеи, которые ложатся в основу всего: структуры, содержания, взаимодействия с пользователями.
Например, основная идея «Заботливая компания — заботливый сайт» и вытекающие из неё решения: подсказки при изучении сайта, возможность бесплатной консультации, статьи с советами, приятные лица сотрудников вместо обезличенного текста, отсутствие препонов вроде регистрации и капчи для заказа, подстройка под разные устройства, учёт сценариев захода на сайт и т.д.
Структура и содержание
Список разделов и меню.
Меню, список разделов и страниц с кратким содержанием.
Полный список разделов и страниц с задачами и точками входа, подробным содержанием и системой навигации (продумана каждая ссылка и переход).
Взаимодействие с пользователями
—
«Покажем посетителю, что заявка отправлена. Наверное, нужно ещё подтверждение на почту прислать.»
Проработанные и описанные процессы обработки информации и взаимодействия с пользователями в разных ситуациях: например, в каких случаях и как предлагается консультация, как проходит, сохраняется и анализируется, как начинается и подтверждается запись на тест-драйв или бронирование номера, кто за что отвечает в это процессе. И снова для примера кусочек такого описания: https://yadi.sk/i/g3hKz2bxepMGW, https://yadi.sk/i/x0mbch5QepMLr.
Прототип
Наскоро собранный из типовых элементов, без описания.
Нормально собранный, но обычно без описания. «Да там всё понятно».
Внешне мало отличается от тех, что слева, но тщательно продуман, с подробным описанием логики работы каждого элемента: кнопки, ссылки, блока и т.п. И ещё в нём учтено всё, что сделано раньше.
Управление
«Поможем выбрать CMS.»
«Поможем выбрать и, наверное, настроить CMS.»
Продуманное управление содержанием и процессами, с учётом роли и прав каждого пользователя.
Советы по выбору CMS или даже специально спроектированная система управления со своими персонажами, сценариями, процессами.
Структура данных
—
—
Описание каждого вида данных: поля, свойства и связи.
Проектное задание
«ТЗ заказчика — это разве не оно?»
Большой документ на непонятном техническом языке, скорее для программистов.
Понятный документ на русском языке, описывающий логику работы, здорово дополняющий схемы и прототип.
Контроль разработки
«Сами разберутся.»
«Ответим на вопросы.»
«Поясним все документы, поможем построить процесс [разработки и контроля], проверим результат.»
Подготовка содержания
«Контентом мы не занимаемся.» или «Наш seo-копирайтер всё сделает!». Второе хуже.
«В прототипе всё показано.»
Советы по каждому типу содержания: задачи, состав, размер, стиль; постановка задачи [копирайтеру или дизайнеру] и проверка результатов.
Тестирование
—
«Проверим, что там программисты сделали»
Тестирование на настоящих пользователях с настоящим содержанием по настоящим сценариям + выводы, что и как нужно улучшить.
Что нужно от заказчика
Мм, всё, кроме самого прототипа — придумать структуру и содержание, сказать, что требуется от системы управления…
Тут уже получше: «проектировщик» не только спрашивает, но и предлагает решения.
Активно помогать при сборе информации — ответить на вопросы по бизнесу, предоставить материалы, организовать интервью с клиентами — и согласовывать результаты. Всё остальное делает проектировщик.
Да, заказчик здесь тратит довольно много времени, но, что важно, решения принимает и защищает тот, кто и должен — проектировщик.
Результат
Не очень продуманный и частенько оторванный от реальности прототип.
И больше ничего. Голая внешняя часть сайта.
Симпатичный прототип с каким-то описанием логики работы и иногда советами по содержанию.
Здесь вырисовывается хоть какая-то система.
Много полезной для проекта и бизнеса информации, обоснованные и продуманные до мелочей архитектура, управление, взаимодействие с пользователями, проверка решений.
Простыми словами: продуманная система, которая нацелена на пользователей и ваши задачи, а не собрана из кусочков мнений, примеров сайтов и «модных» решений.
И несколько мыслей напоследок.
Контроль и тестирование? Мне возразят — и ведь возражают, — что это уже не работа проектировщика. А чья? Кто лучше него проверит и увидит ошибки, скажет, как их исправить? Есть такое понятие — «авторский надзор». При разработке сайтов/информационных систем он просто необходим, иначе разработчики и заказчик сделают что-то своё, часто далёкое от проекта и потому плохо работающее.
Важна системность Проект — это структура и содержание, система навигации, бизнес-процессы, правила обработки информации, структура и связи данных… Если что-то забыть, всё может полететь в тартарары.
Например, недавно мне показали симпатичный интерфейс сервиса для обмена валют. Всё в нём хорошо — цвета, формы, вёрстка, учтены особенности разных валют, — только вот бизнес-процесс подвёл. Сервис предлагает посетителю ввести сумму и выбрать валюту, которую он хочет получить, и подтвердить перевод. С его счёта списывают деньги и…, если сумма превышает 1 000 долларов, требуют авторизации и подтверждения личности с помощью скана паспорта. Эээ… Почему мне не сказали об этом, когда я вводил сумму? И тут самое весёлое: после проверки перевод может быть отклонён, а возврат осуществляется по правилам платёжной системы, т.е. в ряде случаев — до 30 дней. Как вам?
Почему пока что проектирование = прототип? Прототип — это самая наглядная часть проекта, поэтому он так всем нравится и его легко продать. Я не хочу сказать, что прототип не важен или не нужен. Просто проектирование — это не только прототип.
Если проектировать без серьёзного сбора и анализа информации и всего перечисленного, получится дикая смесь пожеланий заказчика и шаблонов в голове прктрвщка вроде «Как же без баннера с прокруткой на главной странице!».
Проектирование не заканчивается на прототипе, а только начинается.
Докажи! Я понимаю, что в конце вам хочется увидеть примеры плохого и хорошего результата. Я бы рад, да не выйдет. Вся суть в том, что по прототипу (и даже сайту) нельзя сказать, насколько хорошо он спроектирован в целом. Он может быть симпатичным, логичным, удобным, с прекрасно работающими отзывчивыми элементами — это всё здорово, но только если решены задачи, а это на вид не определить. Я могу показать внешние отличия, и будет очевидно, где сделали тяп-ляп, а где подумали, но это лишь верхушка айсберга, за которой стоит гораздо больше.
В следующей статье я постараюсь раскрыть всю глубину проектирования и показать, какую пользу оно приносит заказчику, помимо лежащей на поверхности проектной документации. Вот тут уже будут примеры из жизни.
Автор: Александр Туник, Проектная студия «Тектоника» (Руководитель и проектировщик)
Рекомендуем:
Рекомендации по созданию прототипов для юзабилити-тестирования
В этом обзоре собраны рекомендации, касающиеся того, как сделать эффективнее проверку эргономичности и избежать проблем при тестировании прототипов.
22 ошибки в юзабилити российских (и не только) интернет-магазинов, а также работающие варианты по их исправлению
Все мы очень хотим найти ошибки, просто их исправить и сразу же получить результат. Или вместо этого, порассуждать на тему того, ошибки ли это, и что даст или не даст их исправление. Для многих, это даже более интересно.
15 требований к оформлению прототипа
Прототип интерфейсов (в нашем случае сайта) — это не только один из этапов проектирования, но и самостоятельный продукт, с которым далеко не всегда работает та же команда, что его создавала. Поэтому мы составили требования к оформлению прототипов. Сначала они были внутренними, но как только мы начали поиски новых проектировщиков, оказалось, что эти требования могут быть полезны не только нам, и мы сделали этот материал.
Красиво и полезно? Или как найти баланс в проектировании и не заиграться в дизайн
В проектировании интерфейсов, как и в любой другой сфере, порой нелегко соблюсти баланс интересов клиента и исполнителя.
Полный текст статьи читайте на CMS Magazine
