Воркшоп был рассчитан на тех, кому нужно спроектировать какой-то логический кусок системы — сценарий. Так я называю один или несколько экранов, объединённых одной задачей пользователя.
Для примера мы взяли сценарий регистрации в приложении банка. Он кажется простым, но на самом деле любые другие более сложные сценарии собираются по тому же принципу и вырастают из одного как ветки из дерева. В основе проекта древо сценариев, которое позволяет делить его на куски.
Классический подход: пишем ТЗ
Если бизнес-заказчики знают чего хотят, работа по проекту обычно начинается с большого старательно написанного технического задания.
Те, кто пишут ТЗ, выкладываются по полной, чтобы оно было исчерпывающим и описывало все поля и все чекбоксы, которые применяются в продукте. Поэтому, ТЗ легко может достигать сотни страниц.
Так оно становится тяжеловесным и водянистым. И конечно, не делает процесс понятнее и не ускоряет его.
Очень важно, чтобы задача была поставлена понятно, а для этого она должна быть сформулирована компактно, чтобы помещаться в голове. Детали, необходимые для реализации, могут быть в виде прототипов или вики-сайта в Конфлюенсе или Notion. Максимальный объём правильного ТЗ — две страницы текста.
При неудачном раскладе через месяцок окончательно утверждённое и вымученное ТЗ достигает дизайнеров. Дизайнеры его отрисовывают и отдают в разработку. От начала работы до релиза может проходить год.
В чём ошибка такого подхода?
ТЗ, вместо того чтобы обрисовать проблему и дать пространство для её наилучшего решения, предлагает какое-то гипотетическое решение, не проверенное конечными пользователями, и скорее всего нежизнеспособное. Зато утверждённое! Затем в ТЗ вносятся правки, процесс повторяется. Пока не закончится финансирование.
И очень часто дизайнеры даже не имеют права на него как-либо влиять. Им говорят: ты дизайнер — вот и рисуй, а в бизнес-процессы не лезь.
Одного лишь ТЗ для развития проекта недостаточно. Нужен способ синхронизации идей в команде и коллаборация, и здесь на помощь приходят прототипы и Фигма. Потому что, читая ТЗ, каждый выстраивает у себя в голове какой-то свой визуальный ряд и логику.
Решение: быстрые прототипы
Когда есть хотя бы какой-нибудь прототип, у всех вдруг появляются глаза. Понимание проекта естественным образом синхронизируется.
Даже схематичные прототипы отлично передают дизайн-решения.
Чёрно-белого не очень красивого прототипа вполне достаточно, чтобы объяснить интерфейс любой сложности всего за несколько картинок.
Проектировщик в этой ситуации это проводник с фонарём, который освещает дорогу всей команде на то, как продукт может выглядеть и работать и как на него будут реагировать пользователи.
Идеальное ТЗ не занимает больше двух страниц текста.
Однако, у прототипов тоже есть ловушки.
Общее правило — не тратить на их создание много ресурсов.
Опасность 1. Преждевременное вырисовывание
Прототипы не обязательно должны демонстрировать финальный дизайн. Увы, многие дизайнеры, особенно, сильные в графике, склонны к перфекционизму, который на старте проекта вредит. Они слишком быстро бросаются рисовать красивые картинки и стремятся детализировать свой дизайн, хотя ещё не сформировался флоу. Сам делал эту ошибку.
Раньше я не фокусировался на смысле взаимодействия, а стремился как можно скорее облагородить макеты, потому что «ну позорно же выглядит и стыдно перед людьми, тыж дизайнер!»
Опасность 2: Прототипы делают слишком долго
Это касается в первую очередь HTML и Фреймера. И когда они закончены, они уже никому не нужны.
Если на разработку прототипа нужно сопоставимое время, за которое можно забилдить проект, что-то явно не так.
Бизнес-требования могут выглядеть так:
Мы представляем себе цель пользователя и исходим из неё.
Из письма или устного описания мы узнаём, какие данные нам нужно снять с пользователя, чтобы пропустить его в авторизованную зону.
Выделяем модель данных пользователя
Эти данные лягут в основу того, что я называю моделью данных. Прямо в Фигме создаём список, который всегда будет перед глазами:
- Логин
- Пароль
- Телефон
- Почта
- Код из СМС
Удобство в том, что если это будет в Фигме, нам не нужно будет переключаться на текстовую версию бизнес-требований, а работать исключительно в редакторе.
Практика
- Проектируем UI Kit. Набрасываем необходимый минимум компонентов: поля ввода, кнопки, клавиатуру, чекбокс, иконку «Назад».
- Накидываем экраны, исходя из задачи пользователя
- Прорабатываем состояния ошибок
- Расставляем связи в режиме Prototype
- Прокликиваем в Figma Mirror
Выводы
- Прототип создан быть выкинутым
- Чем меньше сил затрачено на изготовление — тем лучше.
- Если есть цвета и фото, уже воспринимается как страшненький дизайн. Если их нет — как схема взаимодействия. То, что нужно!
- Собирай прототипы за минимум времени и тестируй взаимодействие, а не визуал
- Проект сам себя документирует. ТЗ — это готовые макеты.
- Подход позволяет визуализировать как можно раньше и видеть ляпы
Figma – как доска на стене в офисе, которую невозможно не видеть. Она создаёт единое инфополе, в рамках которого все продолжают мыслить и генерировать решения. Когда есть такой прототип, всем в команде становится понятно, что дальше делать. Его можно показывать руководству и работать не над сложным многостраничным ТЗ, а над легковесным работающим прототипом, который дёшево переделывать и править в облаке.