Привет! Меня зовут Владимир Крылов, и я проектирую внутренние сервисы в Ozon.

Продуктовые дизайнеры упаковывают решения проблем в макеты, которые часто смотрят коллеги: другие дизайнеры, менеджеры, аналитики, разработчики и QA-инженеры. Важно, чтобы макеты были максимально понятными — это сэкономит время на погружение в задачу всем участникам процесса и снизит количество ошибок, которые придется потом исправлять. Поэтому понятные и удобные макеты сокращают Time to Market продуктовых решений.

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

Расскажите о задаче

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

В таком блоке можно размещать следующую информацию:      

Дата, статус и ссылка на задачу

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

Контекст

В описании лучше обозначить проблему или рассказать о целях, сути задачи, разделе продукта, что меняем и зачем. Понятное описание не только введёт в курс дела, но и позволит лучше понимать дизайн-решения.

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

Ссылки

Удобно, когда под рукой сразу ссылки на другие артефакты, связанные с задачей: документация, результаты исследований, дашборд аналитики, доски в Miro или FigJam. Так материалы не потеряются, и к ним можно быстро вернуться из макетов. Если возможно, старайтесь размещать ссылки, которые не потеряют актуальность со временем.

Дополнительно

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

Добавьте пользовательский путь

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

В Figma для соединения экранов стрелками используют плагин AutoFlow, коннектор из FigJam или компоненты. AutoFlow соединяет экраны стрелками через зажатый «Shift» и сохраняет связи при перетаскивании, но бесплатно доступно только 50 стрелок на момент публикации.

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

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

Выделяйте сценарии

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

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

Если корнер-кейсы мешают считывать главный сценарий, вынесите их отдельно и оставьте на странице карточку-ссылку там, где это нужно.

Объединяйте в секции

Объединяйте сценарии и функциональные области в секции. Разделение на группы помогает ориентироваться на странице и дает возможность помечать частями макет статусом «Ready for dev». В Dev Mode отмеченная «Ready for dev» секция отображается как отдельная группа, и по ней видны последние изменения. Так команде будет удобно ориентироваться и отслеживать готовность сценариев.

Подробнее о Dev Mode писали в статье «Скажи что-нибудь на разрабском, Figma» от Виктора Теплова.

Выносите локальные компоненты 

Локальные компоненты объединяйте в отдельную секцию. Секции отображаются как папки в меню выбора и на панели Asset, а в режиме просмотра команде будет удобно отслеживать, что в макете собрано на локальных компонентах.

Добавьте названия экранов

Figma умеет искать по названию фреймов, тексту и компонентам. Такой поиск работает и в Dev Mode. Если называть экраны осознанно, их будет проще найти в крупных сценариях.

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

Кстати, чтобы быстро пронумеровать экраны: упорядочите фреймы опцией Smart Sort Layers в плагине Clean Document, выделите фреймы сценария и переименуйте c помощью встроенного Rename (сmd + R), используя формулу 1.$n $&.

Если нужно поменять текущую нумерацию сценария: выделите его, откройте панель Rename (сmd + R), поставьте в Match формулу ^(\d*.\d*), а в Replace with – 2.$n

Заполните описания компонентов

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

В описание компонента можно добавить целое облако тегов для быстрого поиска в меню выбора и на панели Assets. 

Оставьте записки с важной информацией

Любую важную информацию лучше оставлять в виде записок-стикеров на макете. Это могут быть изменения, ограничения, текстовки, размеры и прочее. Оставлять записи лучше в виде виджетов вроде Annotation Sticky Notes или фрейма. В отличие от комментариев такие записки видны сразу, их нельзя скрыть кнопкой «resolved» и не нужно каждый раз открывать, чтобы прочитать. Фреймы-записки вместе с юзер-флоу работают как полноценная спецификация.

Сначала кажется, что писать нечего, тогда для начала соберите частые вопросы разработчиков и отвечайте на них в записках заранее. Как писала Катя Колегова в своём посте , — «вопрос разработчика — моё досадное упущение». Вместе с этим писать можно о багах, идеях и статистике. Важно обсудить всё с командой и убрать записки, которые могут оказаться неактуальными.

Опишите подробнее

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

Сделайте прототип

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

Поделитесь результатами юзабилити-тестирования

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

Подбирайте оформление под задачу

Оформление макетов часто зависит от задачи или специфики продукта. Если вы делаете адаптив экрана или проектируете компонент «пустого состояния», то можно обойтись без контекста и сценариев. Излишнее оформление только путает и отнимает ваше время.

Вместо заключения

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

Бонус к статье: шаблон для Figma

Подготовил шаблон с артефактами по оформлению из этой статьи без привязки к стилю Ozon, чтобы вы могли адаптировать его под себя.

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

Если знаете ещё способы, как можно сделать макеты удобнее для команды, поделитесь в комментариях.

Подписывайтесь на телеграм-канал Ozon Design — коллективный аккаунт ведущих дизайнеров Ozon, где мы делимся опытом и своими мыслями.