Как у нас происходит процесс передачи макетов разработчикам

Важной частью работы дизайнеров является передача интерфейсов в руки фронтенд-разработчиков (mobile и web). Но, между творческим замыслом дизайнера и его воплощением в коде может возникнуть немало трудностей.

В этой статье мы хотели показать как это происходит у нас: какие подходы и инструменты используем, как отмечаем состояния готовности и др.

Выбор инструмента

Сегодня стандартом в отрасли является редактор Figma. Поэтому дизайн-процесс будет показан на основе данного инструмента.

Структурируем макеты

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

1. Присваиваем логичные названия страницам и фреймам (например: Главная/Каталог/Карточка товара);

2. Разделяем макеты по функциональной принадлежности (рис.1)

(рис.1) Разделы по функциональной принадлежности Новости и Меню

3. Переходы между экранами обозначаем стрелками и комментариями, чтобы логика взаимодействий была сразу понятна. (напр: Кнопка "Далее" → Экран оплаты). 

Можно использовать плагины, либо стандартные стрелки из FigJam (рис.2) (если копировать такую стрелку из FigJam в обычный фигма-файл, она сохраняет возможность прилипать к объектам).

(рис.2) Пример связи с помощью стрелки с подписью в FigJam

Документация сразу внутри макета

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

Какую информацию мы показываем:

Состояния элементов - изображаем, как элемент выглядит в разных состояниях (hover, active, loading, disabled);

Состояния экранов - отображаем все возможные состояния экрана (загрузка, ошибка, пустой экран);

Адаптивность - учитываем разные размеры экранов и устройств (рис.3);

(рис.3) Пример адаптированных экранов под разные устройства

Аннотации - добавляем комментарии к сложным элементам, разъясняющие их функциональность или особенности реализации. Для этого мы используем компонент заметок из Figma Community (рис.4-5).

Такие аннотации особенно полезны в случаях:

• Сложной логики (Conditions);

• Обновлении контента (Update);

• Добавлении новых экранов (New);

• Изменении макета (Changes);

• Моменте для уточнения (Question);

• Фиксации необходимой информации (Note).

(рис.4) Пример наших комментариев

(рис.5) Пример оформления комментариев на макете

UI-Kit

Для упрощения процесса разработки и обеспечения единообразия интерфейсов мы разрабатываем UI-Kit к каждому проекту – библиотеку готовых компонентов интерфейса.

UI-Kit включает в себя:

• Базовые элементы интерфейса (кнопки, поля ввода, иконки и т.д.);

• Готовые шаблоны экранов;

• Правила использования компонентов и стилей.

Адаптивность и сетка

Тип устройства	Flutter	Web
Мобильный	375×812	360px
Планшет	768×1024	768px
Десктоп		1440px

В качестве базовой единицы сетки мы используем шаг в 4 пикселя. Все отступы в макетах должны быть кратны этой величине — допустимые значения: 4, 8, 12, 16, 24 и 32 px. Это позволяет поддерживать визуальную согласованность и упрощает адаптацию интерфейса под разные экраны.

Также необходимо учитывать Safe Areas для мобильных устройств:

– верхний отступ — 44 px (для статус-бара);

– нижний отступ — 34 px (для индикатора Home);

– боковые отступы — от 16 до 20 px (рекомендуемые значения для комфортного восприятия).

1. Стили

Для оформления интерфейсов мы используем заранее настроенные текстовые и цветовые стили.

1) Текстовые стили именуются по следующей схеме: 

Тип / Назначение / Размер (например: Heading/H1/32px). Это позволяет быстро ориентироваться в иерархии заголовков и текстовых блоков.

2) Цветовые стили оформлены с использованием иерархического именования: Цвет / Градация (например: Blue/500).

Каждому цвету соответствует набор градаций (рис.6):

• 50–100 — светлые;

• 200–400 — средние;

• 500 — основной;

• 600–900 — тёмные;

• 950 — насыщенный.

(рис.6) Стили цветов

2. Компоненты

Все интерфейсные элементы хранятся централизованно в составе UI-Kit. Почти все из них построены с использованием Auto Layout, что обеспечивает гибкость и удобство при редактировании.

Для каждого компонента в UI-Kit отображаются все необходимые состояния, соответствующие различным сценариям использования:

Состояние	Описание
Default	Обычное состояние
Hover	При наведении курсора
Active / Pressed	При нажатии
Disabled	Неактивное состояние
Focused	Активное состояние ввода (для полей, кнопок, ссылок)
Error	Состояние с ошибкой (если применимо)
Success	Подтверждение успешного действия (если применимо)

3. Иконки

Иконки оформляются по следующим правилам (рис.7):

• помещаются в фреймы фиксированного размера: 16×16 или 24×24;

• векторный объект внутри должен быть в режиме Scale;

• все иконки объединяются в Variants для удобства использования;

• используется схема именования: ic/[название] (например, ic/trash).

(рис.7)Иконки объединенные в Variants

4. Кнопки

Все кнопки объединяются в Variants, все параметры компонента указываются в панели свойств (рис.8):

• State — состояние кнопки (Default, Hover, Disabled и др.);

• Type — стиль кнопки (Solid, Stroke, Ghost и др.);

• Size — размер кнопки (Small, Medium, Large и др.).

• Именование автоматическое, см. подпункт выше.

5. Поля ввода:

Поля ввода также оформляются в виде Variants с аналогичной структурой параметров (рис.8):

• State — состояние поля (Default, Focus, Disabled и др.);

• Variant — стиль поля (Filled, Outlined и др.);

• Size — размер поля (Small, Medium, Large и др.).

Примечание: Для каждого компонента параметры в Variants должны быть выбраны в зависимости от контекста использования.

(рис.8) Параметры Variants

6. Графика

Для растровых изображений используем формат PNG с плотностью @2x/@3x и разрешением 72 DPI — этого достаточно для корректного отображения на большинстве экранов, включая веб.

Векторные изображения сохраняем в формате SVG с предварительно объединёнными контурами — это обеспечивает корректное масштабирование и отображение в разных средах.

Для удобства навигации и повторного использования вся графика организована следующим образом:

• растровые и векторные изображения хранятся в разделе Assets;

• иконки — в отдельном разделе Icons внутри UI-Kit.

7. Анимации и интерактивность

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

• Выбираем простые эффекты, которые легко реализовать;

• Для сложных анимаций даём разработчикам подробное описание или референсы, а если проект на Flutter — сразу прикладываем ссылку на нужную анимацию из библиотеки;

• Стараемся не перегружать интерфейс лишними анимациями.

Формат передачи анимаций в макетах:

Платформа	Простые анимации	Сложные анимации	Rive / Lottie
Web	Figma Smart Animate	Описание + референс	.riv / .json
Flutter	Figma Smart Animate	Описание + ссылка на анимацию из библиотеки	.riv / .json

Частые ошибки

Во избежание недопонимания и сбоев на этапе разработки мы обращаем внимание на следующие типовые ошибки:

• Неупорядоченные слои (например: Rectangle 234, Group 12);

• Отсутствие комментариев к неочевидным элементам интерфейса;

• Дублирование компонентов в UI-Kit;

• Размытые изображения с разрешением ниже 72 DPI;

• Пропущенные этапы прототипирования, информационной архитектуры и построения User Flow.

Финальная проверка

Перед тем как передать макеты разработчикам, мы обязательно проверяем их по чек-листу, чтобы ничего не упустить:

• Указаны все состояния экранов.

• Все компоненты из UI-Kit;

• Стрелки переходов между экранами;

• Комментарии к сложным элементам;

• Тег статуса "Готово к разработке";

• Проверена адаптивность дизайна.

Заключение

Упорядоченная система в дизайн-процессе предрасполагает не только к продуктивной коммуникации в команде, но и к скорости передачи макетов заказчику. А также экономии бюджета разработки.

В следующих материалах по дизайну, мы покажем как мы оптимизируем коммуникацию с заказчиком.