Привет! Меня зовут Анна, я маркетолог команды цифровой трансформации Ареал.
Более чем за 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. Согласовать с подрядчиком и клиентом процесс взаимодействия.
