История жизни одного макета. Как мы унифицировали правила работы с дизайном

Раньше мы использовали канбан, но перешли на секции как только они появились в Figma. Они удобнее с организационной точки зрения — секции можно двигать, тогда как система канбана была статичной. Ее трудно было расширить при увеличении количества макетов.
Полина Иванова
ведущий специалист департамента UX/UI и дизайна

Сбор референсов

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

Создание прототипа

Один из важных этапов — правильно назвать фрейм. Общепринятых стандартов наименования фреймов нет, но мы внутри следуем правилам:

• Название каждого фрейма уникально. Это упрощает поиск в слоях и исключает конфликты при экспорте макетов. Названия пишутся на латинице или кириллице.
• Если необходимо, то проектировщик указывает роль, для которой актуален интерфейс. «ФЛ. Регистрация», «Главный сварщик. Аттестации НАКС. Список».
• Если у макета несколько состояний зависящих от поведения, то проектировщик указывает актуальное для страницы. «Каталог. Скролл вверх» и «Каталог. Скролл вниз», «Карточка товара. В корзине» и «Карточка товара. Добавить в корзину».

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

Если макетов на странице много и их нужно разделить по какому-то признаку, то внутри проектировщик создает вложенные секции. Например, в прототипе авторизации, — авторизация по смс, авторизация почта+пароль. Эти секции должны иметь название. Мы стараемся не частить с вложенными секциями, чтобы не засорять артборд.

Готовый прототип уходит на согласование внутри и с клиентом. Статусно в макете это не отображается, потому что согласование прототипа происходит динамично.

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

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

Создание дизайна

От первого варианта дизайна до финального макет проходит путь, которому соответствуют статусы:

• Дизайнер собирает концепт и присваивает макету соответствующий статус. Интерфейс проходит отработку решений, согласуется с арт-директором, потом с клиентом.
• Дизайнер по утвержденному концепту рисует макет интерфейса. Когда работа закончена специалист переводит макет в статус Review — процессный статус, сигнализирует арт-директору, что можно брать страницу в работу.
• Арт-директор делает ревью макета, оставляет комментарии и переводит страницу в статус Change. Так дизайнер понимает, что можно отрабатывать комментарии.
• Дизайнер корректирует макет, опять переводит его в статус Review, чтобы ответственный видел, с какими макетами можно работать.
• В процессе какие-то интерфейсы могут быть выведены из работы. Тогда дизайнер присваивает макету статус Archive и затемняет его.
• Арт-директор финально согласует интерфейс, присваивает статус Approved.
• Заказчик принимает макет. Это может происходить онлайн — созвон с дизайнером и арт-директором, руководителем проекта, на котором клиент дает комментарии. Либо заказчик оставляет комментарии непосредственно в макете. При наличии правок страница возвращается к дизайнеру и идет на еще один круг согласований. Если правок нет, то руководитель проекта или дизайнер по согласованию с РП переводит макет в статус In dev и перемещает его из секции Design в Dev. Именно исходник, а не копию, чтобы не создавать две ветки и не путать исполнителей.Если макетов в разработку передается много, то секция или целая страница отмечаются штатным инструментом Figma «Передано в разработку».

Статусы дают команде понимание, на какой стадии находится интерфейс, готов ли он к передаче далее по процессу, облегчают ориентацию на странице.

Лейблы реализованы через компонент, смена статуса осуществляется в настройках состояния.

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

Модификация интерфейса

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

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

Ворклог в Figma — история изменений со статусом, датой, исполнителем и самими правками. Инструмент в основном для дизайнера или проектировщика, арт-директор использует в процессе ревью.

Шаблон ворклога сделан нами кастомно. Преимущества:

• Дизайнер ориентируется в изменениях здесь и сейчас.
• Хранит историю корректировок: кто, что и когда изменил.
• Позволяет оставлять ссылки на элементы макета, что особенно удобно в сложных интерфейсах.
• Можно вести один ворклог на группу макетов, когда правки коснулись нескольких интерфейсов.
• Если версий макета или группы макетов более одной, ворклог позволяет разобраться в изменениях для конкретного варианта интерфейса.

Сборка макетов дизайна

Программист работает с макетом преимущественно в Dev mode. Режим предоставляет информацию о дизайне: стили, компоненты, позиционирование элементов, размеры, отступы, шрифты, код в различных форматах CSS, Swift, Android, XML и т. д.).

Когда интерфейс доставлен на прод, руководитель проекта меняет статус макета на Done. Так команда знает, работа с какими интерфейсами уже закончена на текущей итерации.

Модификация интерфейса

В момент верстки тоже может произойти модификация. Ее процесс немного сложнее, чем на этапе дизайна.

• Если сборка страницы началась, а корректировки не критичные, то разработчик продолжает верстать интерфейс. А копия интерфейса уходит на цикл модификации: проектирование -> согласование -> дизайн -> согласование -> разработка.
• Если корректировки серьезные или фронтендер еще не взялся за макет, то задача в секции Dev ставится на паузу и проектировщик начинает вносить правки. Макет при этом возвращается на первый этап — создание прототипа, а затем проходит весь цикл до разработки.

Вне зависимости от варианта модификации изменения интерфейса фиксируются в нескольких артефактах:

• Проектировщик для дизайнера и арт-директора пишет ворклог, отмечая, что именно исправлено.
• Дизайнер в Dev mode пишет аннотации к изменениям, чтобы их увидел разработчик.
• Руководитель проекта корректирует задачу в Git, так как это основной источник знаний для разработчика. Иногда оставляет в задаче ссылку на ворклог, если он помогает разобраться в модификации.
• Аналитик или руководитель вносят изменения в техническое задание как критерий приемки задачи.

Поддержка UI Kit

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

• Подрядчик по клиентской задаче делает прототип, макет дизайна на основе библиотеки, согласует их с клиентом.
• Если возникают изменения в элементах, компонентах подрядчик согласует визуальные решения с держателем библиотеки с нашей стороны. Как правило, это ведущий дизайнер клиентского проекта.
• При необходимости дорабатываются элементы библиотеки.
• Внесенные изменения дизайнер передает в библиотеку фронтэнд компонентов.
• Наши разработчики корректируют библиотеку.
• Держатель библиотеки проверяет макет на соответствие UI Kit.
• Подрядчик разрабатывает интерфейс по макету.

Заключение

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

Основные этапы и правила в бизнес-процессе создания макета, которых мы придерживаемся:

• Создание файла. В названии использовать маркеры, а на обложках теги.
• Подключение библиотеки UI компонентов. Использовать свою систему как основу даже на проектах с кастомным дизайном, дублировать и развивать клиентский вариант в отдельном файле.
• Создание структуры страниц в файле. Отражать в структуре процесс работы с проектом.
• Настройка артборда. Организовать пространство через секции Dev, Design, Prototype, Refs, которые отражают жизненный цикл макета.
• Работа со слоями и фреймами. Присваивать уникальные названия, не использовать много вложенных секций.
• Согласование результатов. Использовать статусы — Concept, Review, Change, Approved, Archive, In dev, Done.
• Модификация интерфейса. Фиксировать изменения в ворклоге, аннотации в Dev mode, задаче в Git, техническом задании.
• Поддержка UI Kit. Согласовать с подрядчиком и клиентом процесс взаимодействия.