Привет! Меня зовут Владимир Крылов, и я проектирую внутренние сервисы в 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, где мы делимся опытом и своими мыслями.
Читайте другие полезные материалы Ozon для дизайнеров.
