Прктрвнье, «проектирование» и проектирование

Маркетинг9 Контекстная реклама9 Создание сайтов9 SEO6 Комплекс услуг4 Дизайн8 Программирование9 Использование сервиса3 Digital2 SMM3 Юзабилити3 Мобильная разработка Брендинг1 Менеджмент1 Интернет-маркетинг2 Интранет1

Интернет-маркетингСтатья

КритикаUsability (удобство использования)ПрототипированиеСравнение

Проектирование — это не прототип накалякать.

Александр Туник

10 марта 2015

1 848

Проектирование вошло в моду, его делают уже в каждой подворотне. Статьи по 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 дней. Как вам?

Почему пока что проектирование = прототип?

Прототип — это самая наглядная часть проекта, поэтому он так всем нравится и его легко продать. Я не хочу сказать, что прототип не важен или не нужен. Просто проектирование — это не только прототип.

Если проектировать без серьёзного сбора и анализа информации и всего перечисленного, получится дикая смесь пожеланий заказчика и шаблонов в голове прктрвщка вроде «Как же без баннера с прокруткой на главной странице!».

Проектирование не заканчивается на прототипе, а только начинается.

Докажи!

Я понимаю, что в конце вам хочется увидеть примеры плохого и хорошего результата. Я бы рад, да не выйдет. Вся суть в том, что по прототипу (и даже сайту) нельзя сказать, насколько хорошо он спроектирован в целом. Он может быть симпатичным, логичным, удобным, с прекрасно работающими отзывчивыми элементами — это всё здорово, но только если решены задачи, а это на вид не определить. Я могу показать внешние отличия, и будет очевидно, где сделали тяп-ляп, а где подумали, но это лишь верхушка айсберга, за которой стоит гораздо больше.

В следующей статье я постараюсь раскрыть всю глубину проектирования и показать, какую пользу оно приносит заказчику, помимо лежащей на поверхности проектной документации. Вот тут уже будут примеры из жизни.