Как передавать макеты в разработку

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

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

Не будем затягивать и начнем. Давайте для начала обозначим тот минимум, который у вас обязательно должен быть, чтобы можно было отдавать дизайн на разработку.

Макеты со всеми основными экранами, сценариями и состоянием элементов

На первый взгляд это может показаться банальным пунктом, но это не так. Обычно начинающие дизайнеры рисуют макеты просто как картинки. Нарисовали экран и все на этом. Но на деле, когда пользователи начнут взаимодействовать с интерфейсом, то они могут проходить по разным веткам сценариев. И на пути к своей цели пользователи могут сталкиваться, например, с ошибками системы. Банальный пример — валидация полей ввода при введенных некорректных данных. 

Такие ситуации тоже следует учитывать при дизайне и отрисовывать разные состояния интерфейса. Например, если вы проектируете форму регистрации, то недостаточно будет просто нарисовать саму форму. Покажите как форма будет выглядеть, если возникнут ошибки. Абсолютно все однотипные ошибки отрисовывать не стоит, потому что у них будет меняться только текст ошибки, но хотя бы одну отрисовать нужно, чтобы разработчики понимали, как обрабатывать такой сценарий. 

Пример с регистрацией достаточно простой и кто-то может сказать, что в UI-ките и так будут показаны состояния полей ввода при ошибках. Отчасти это правда, но у таких форм могут возникать не только ошибки при валидации по вине пользователя. Также могут быть и ошибки с бекэнда, которые тоже следует учесть и показать как это будет выглядеть. Да и в дизайне помимо форм есть и другие места, в которых могут возникать ошибки. Пример с формой привел просто для наглядности.

Помимо ошибок, пользователей желательно еще уведомлять и об успешных событиях. Если вы хотя бы раз делали перевод в приложении любого крупного банка, то могли заметить, что после перевода вам выводится экран, в котором говорится, что перевод на такую-то сумма осуществлен. Это и есть уведомление об успешном событии. Интерфейс дает вам обратную связь, что вы сделали все правильно и ваша цель достигнута. 

Все эти состояния следует отображать на макетах, чтобы разработчики не ломали голову и не задавали вам лишних вопросов: «А что делать в этой ситуации?». Чтобы ничего не забыть и по-максимуму отобразить все на макетах, дизайнеры используют такой инструмент, как User Flow, но о нем чуть позже.

Также старайтесь на макетах показывать не только «идеальные» состояния элементов, но и «жизненные». Под «идеальными» я подразумеваю те, которые красиво вписываются в ваш дизайн. Всегда держите в голове, что любой контент может видоизменятся.

Например, если вы рисуете карточку товара для интернет магазина, то предусмотрите, как она будет выглядеть, если название товара будет слишком большим (а оно обязательно будет) и отобразите это на макете. Иначе, когда ваш интернет магазин обретет жизнь, то можно столкнутся с ситуацией, когда ваши карточки будут разного размера по высоте, из-за того, что в одних будет «идеальный» контент, который вписывается в ваш дизайн, а в других «жизненный» с длинным названием товара на 3-4 строчки.

Подробный UI-kit

Помимо макетов у вас должен быть подготовлен UI-kit, в котором будут отображены все основные элементы дизайна и их состояния. Недостаточно просто нарисовать кнопку или поле ввода. Нужно показать, как эти элементы будут реагировать на наведение на них курсора мыши (для десктопной версии), на нажатие, какой вид у них будет при неактивном состоянии, при выбранном состоянии, при ошибке и т.д.

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

Сюда можно включать:

• Карточки (товаров или просто текстовые блоки с медиа). Здесь как раз можно и показать, как будут выглядеть карточки при разных состояниях и при разном количестве контента в них;
• Навигация (для десктопа и для мобильной версии);
• Модальные и диалоговые окна;
• Аватары с разными размерами;
• Иконки;
• Цвета, шрифты, тени;
• Дропдауны;
• Снекбары и алерты;
• Статусы, теги;
• И так далее;

Все то, что вы переиспользуете в своих макетах обязательно должно быть отображено в UI-ките, чтобы разработчики не метались по вашим макетам, а могли посмотреть все в одном месте. Плюс для вас это тоже будет удобно, потому что в UI-ките у вас будут лежать все мастер компоненты. 

Порядок в рабочей области

Очень часто замечал, что некоторые дизайнеры не уделяют должного внимания этому пункту. Макеты, которые подписаны «Frame 187» и разбросаны в хаотичном порядке по рабочей области — это очень плохо. В такой среде сможет разобраться только тот, кто все это нарисовал, но никак не другой человек.

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

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

Это тот минимум, который 100% должен присутствовать у вас перед тем, как передавать макеты в разработку.

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

Документация

Макеты — это конечно хорошо. Без них никуда. Но иногда только лишь по макетам сложно понять всю логику, которую дизайнер закладывает при проектировании. В этом случае отдельно прописывается документация по дизайну, в которой фиксируются все сценарии взаимодействия пользователя с интерфейсом.

Грубо говоря, в документации словами описываются нарисованные макеты и их логика, а также туда заносится то, что на макетах не отображено. Например, если у вас в интерфейсе предусмотрено несколько снекбаров об успешной операции по какому-то из сценариев, то на макете достаточно показать только 1 вид снекбара с текстом, а тексты остальных снекбаров внести в документацию, чтобы не плодить лишних макетов, потому что в снекбарах будет меняться только текст, а внешний вид будет такой же.

Плюс, если у вас есть документация, то с помощью нее можно легко «освежить» память и вспомнить какую логику вы закладывали в какой-то конкретный сценарий. Это бывает полезно, когда пройдет некоторое время и вам нужно будет, например, добавить некоторые фичи в этот сценарий. Можно открыть документацию, прочитать и все вспомнить. По макетам это будет сделать сложнее.

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

На практике я не раз обращался к документации и это действительно удобно. Что касается разработчиков, то они практически всегда читают документацию прежде чем начинать что-то делать (по крайней мере у нас в компании).

Документацию обычно пишут не сами дизайнеры, а например менеджеры проектов или UX-аналитики. Но все равно вы будете косвенно принимать участие в ее составлении, потому что она основывается на спроектированном интерфейсе. С вами как минимум будут ее согласовывать.

User Flow диаграммы

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

Разработчики обращаются к User Flow не так часто, как например к документации, но все же такое случается. Этот инструмент больше для дизайнеров. Но тем не менее, на его основе отрисовываются макеты, которые потом передаются в разработку.

Плюс по User Flow можно нагляднее посмотреть все ветки сценариев, чем по той же документации. Читать много текста сложнее, чем посмотреть на диаграмму и понять что за чем следует.

Но во всех этих плюшкам есть и минус. Помимо макетов, нужно будет поддерживать в актуальном состоянии как документацию, так и User Flow, чтобы они не противоречили макетам. А это дополнительная работа.

И еще

Не стоит забывать, что все мы люди и бывает сложно с первого раза абсолютно все учесть в дизайне и сделать все «идеально». Поэтому ничего страшного если вы что-то упустили из виду при передаче дизайна в разработку. К вам могут прийти разработчики и уточнить какие-то моменты. Это рабочий процесс.

Просто старайтесь минимизировать подобные вещи, потому что на их уточнение тоже тратится рабочее время. И это не значит, что можно сделать все на отвали и передать в разработку, типа потом если что разберемся. Делайте все по-максимуму. Но если вы что-то упустите, то это можно доработать. Я об этом.

Автор: Георгий Тимофеев

🔥 Не забудьте скачать мою книгу
«от Курьера до Дизайнера интерфейсов»

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