Привет! Меня зовут Анна, я маркетолог команды цифровой трансформации Ареал.
Более чем за 20 лет работы у нас сложилась система шагов и правил для дизайн-процессов. Единые стандарты позволяют команде говорить на одном языке, вести прозрачный диалог с клиентами, быстро ориентироваться в стартовавшем или новом проекте.
В статье я расскажу, как выглядит жизненный цикл интерфейса, и каких правил мы придерживаемся, чтобы соблюдать единообразие и не нарушать методологию.
Мы работаем в Figma, но систему можно организовать в любом редакторе.
Создание файла
Файл создает проектировщик, аналитик, дизайнер, руководитель проекта, в зависимости от того, кто начинает конкретную задачу. Для быстрого считывания сути автор добавляет в название маркеры, а обложку собирает по шаблону.
Маркеры дают понять, к какому виду работ относится макет:
Kit — UI Kit.
Int — интерфейсы.
S — Схемы, Mind Map, User Story, Workflow, etc.
A — audit, benchmarking, etc. (если аудит небольшой, то располагается внутри макетов, либо в схемах).
Prez — презентация.
Основа шаблона обложки — логотип клиента, заголовок и тег.
Заголовок задается по стопам имени файла. В нем может появиться вторая строка — url системы, если в работе несколько площадок одного клиента. Например, корпоративный сайт и личный кабинет.
Теги вторят маркерам, но дополнены цветовой маркировкой, по ней удобнее искать нужный файл визуально:
Int — интерфейсы.
Jam — файл FigmaJam содержит схемы, графики и др.
KIT — UI Kit компонентов.
Prez — презентация.
AUDIT — аудит, тестирование и т. д.
Палитра и типографика обложки выбираются на усмотрение создающего, но по общим принципам:
цвет фона, шрифта и логотипа контрастные;
стиль обложки отличным от других проектов;
в проекте соблюдается единая стилистика обложек.
Редко в папке бывает один файл, поэтому специалистам нужно понимать, когда работать в существующем пространстве, а когда создавать новое. Вопрос решается исходя из целесообразности:
Техническая необходимость. Вес файла стал слишком большим. Возникают проблемы — долго грузятся и отрисовываются макеты, зависает Figma, выдаются ошибки. В таком случае нужно проверить состояние памяти. При достижении 60% лимита файл делится на части.
Чтобы сохранить порядок, в каждом файле дизайнер создает страницу с перекрестным оглавлением, а в названии части проекта указывает номер. На обложке можно добавить основные эпики, которые хранятся в файле.
Особенность взаимодействия с клиентом. Когда разработка идет отдельными заказами, которые сдаются раздельно. В таком случае под каждый заказ ответственный создает свой файл.
Сервис, как следующий большой клиентский проект. Внутри файла задача может перерасти в отдельную разработку. Например, на корпоративном сайте решили функцию предварительного расчета стоимости перевозки превратить в полноценный калькулятор с последующим оформлением заявки в личном кабинете. Подобный эпик, как отдельная система, может быть вынесен в новый файл.
Подключение библиотеки
Библиотека — набор базовых UI компонентов, из которых строятся макеты. UI Kit создается отдельно. Во-первых, когда возникнет потребность вынести UI Kit, это не приведет к потере связей между проектом и библиотекой. Во-вторых, отдельная библиотека подключается к нескольким проектам. В-третьих, ссылку на автономный UI Kit можно дать сторонней команде без доступа к макетам.
За годы разработки ИТ-систем и платформы Wapps мы сформировали свой UI Kit. Он позволяет ускорить прототипирование, именно его проектировщик копирует из шаблонов в клиентский проект и подключает к новому файлу.
Если дизайн планируется частично или полностью индивидуальный, мы все равно работаем со своим UI Kit как исходником. В нем задана структура в нашей логике, настроена перелинковка, выстроены компоненты. Чтобы библиотека соответствовала текущему проекту, дизайнер постепенно вносит корректировки: изменяется логотип, цвета и шрифты приводятся к требованиям брендбука клиента, дорабатываются компоненты согласно драфту дизайна.
Ирина Казанская
аналитик Ареал
Создание структуры страниц в файле
Структура создает и поддерживает порядок среди страниц внутри файла. Главное — она систематизирует процесс работы над проектом. То есть дизайнер переносит в файл все сервисы, разделы или фичи согласно декомпозиции, которые должны быть отрисованы в проекте. Как правило, они организованы от ведущих к второстепенным. Например, для интернет-магазина: главная, листинг и фильтры, карточка товара, корзина и чекаут и т.д.Если на этапе создания файла еще непонятна структура, то дизайнер присваивает странице рабочее название. Впоследствии оно меняется. Но чаще всего основные наименования известны из пресейла.
Для больших проектов исполнитель добавляет разделители:
по релизам, если релизность предусмотрена, — подписывает номера: Р1, Р2 и т.д.
по этапам;
UX/UI — проектирование, в том числе концепт дизайна.
Сборка — сборка макетов разработчиками, из группы UX/UI вся страница перемещается на сборку.
Done — разработка завершена, все страницы выставлены на боевую площадку.
Archive — реализация фичей на этих страницах отменена, сохраняются для истории.
Backlog — по тем или иным причинам в долгосрочной перспективе эти страницы не перейдут в разработку. Страница перемещается в Backlog на любой стадии готовности.
tech - здесь хранится обложка, временные рабочие борды, ворклоги и пр.
Передвигает страницы по этапам руководитель проекта. На практике бывает ситуация, когда программист начал собирать интерфейс, хотя дизайнер еще полностью не закончил работу на странице. В этом случае, макеты не переносятся на новый этап по отдельности. Страница перемещается только целиком, когда текущий исполнитель полностью закрыл задачу.
Разделители по этапам или релизам не работают в проектах сопровождения, потому что не применяется классический водопад. На поддержке каждый эпик живет в своей этапности внутри артборда.
Настройка артборда
Дизайнер приступает к работе на странице. Он создает секции, которые отражают жизненный цикл макета:
Refs — референсы для анализа решений, опыта других проектов.
Prototype — прототипы.
Design — макеты в работе у дизайнера.
Dev — макеты, переданные в разработку.
Для удобства секции выстроены сверху вниз.
Раньше мы использовали канбан, но перешли на секции как только они появились в 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. Согласовать с подрядчиком и клиентом процесс взаимодействия.
