Важной частью работы дизайнеров является передача интерфейсов в руки фронтенд-разработчиков (mobile и web). Но, между творческим замыслом дизайнера и его воплощением в коде может возникнуть немало трудностей.
В этой статье мы хотели показать как это происходит у нас: какие подходы и инструменты используем, как отмечаем состояния готовности и др.
Читать на Habr;
Выбор инструмента
Сегодня стандартом в отрасли является редактор Figma. Поэтому дизайн-процесс будет показан на основе данного инструмента.
Структурируем макеты
Одна из важных задач дизайнеров — не только передать макеты разработчикам, но и сделать это понятно и удобно. Если макеты организованы хаотично, тогда даже самый хороший инструмент не поможет. Как мы это делаем:
- Присваиваем логичные названия страницам и фреймам (например: Главная/Каталог/Карточка товара);
- Разделяем макеты по функциональной принадлежности (рис.1)
3. Переходы между экранами обозначаем стрелками и комментариями, чтобы логика взаимодействий была сразу понятна. (напр: Кнопка "Далее" → Экран оплаты).
Можно использовать плагины, либо стандартные стрелки из FigJam (рис.2) (если копировать такую стрелку из FigJam в обычный фигма-файл, она сохраняет возможность прилипать к объектам).
Документация сразу внутри макета
Важной частью процесса передачи макетов является детализация. Мы стараемся включать в макеты всю необходимую информацию, чтобы разработчикам не приходилось гадать или додумывать, как именно должны работать элементы и экраны в разных ситуациях.
Какую информацию мы показываем:
Состояния элементов - изображаем, как элемент выглядит в разных состояниях (hover, active, loading, disabled);
Состояния экранов - отображаем все возможные состояния экрана (загрузка, ошибка, пустой экран);
Адаптивность - учитываем разные размеры экранов и устройств (рис.3);
Аннотации - добавляем комментарии к сложным элементам, разъясняющие их функциональность или особенности реализации. Для этого мы используем компонент заметок из Figma Community (рис.4-5).
Такие аннотации особенно полезны в случаях:
- Сложной логики (Conditions);
- Обновлении контента (Update);
- Добавлении новых экранов (New);
- Изменении макета (Changes);
- Моменте для уточнения (Question);
- Фиксации необходимой информации (Note).
UI-Kit
Для упрощения процесса разработки и обеспечения единообразия интерфейсов мы разрабатываем UI-Kit к каждому проекту – библиотеку готовых компонентов интерфейса.
UI-Kit включает в себя:
- Базовые элементы интерфейса (кнопки, поля ввода, иконки и т.д.);
- Готовые шаблоны экранов;
- Правила использования компонентов и стилей.
Адаптивность и сетка
Мобильный; Flutter: 375×812 / Web: 360px
Планшет; Flutter: 768×1024 / Web: 768px
Десктоп; Web: 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 — насыщенный.
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).
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 должны быть выбраны в зависимости от контекста использования.
6. Графика
Для растровых изображений используем формат PNG с плотностью @2x/@3x и разрешением 72 DPI — этого достаточно для корректного отображения на большинстве экранов, включая веб.
Векторные изображения сохраняем в формате SVG с предварительно объединёнными контурами — это обеспечивает корректное масштабирование и отображение в разных средах.
Для удобства навигации и повторного использования вся графика организована следующим образом:
– растровые и векторные изображения хранятся в разделе Assets;
– иконки — в отдельном разделе Icons внутри UI-Kit.
7. Анимации и интерактивность
Анимации делают интерфейс более живым и отзывчивым, но их реализация требует аккуратного подхода. Мы используем анимации там, где они действительно улучшают пользовательский опыт, и стараемся избегать избыточности. В работе с анимациями мы придерживаемся следующих принципов:
- Выбираем простые эффекты, которые легко реализовать;
- Для сложных анимаций даём разработчикам подробное описание или референсы, а если проект на Flutter — сразу прикладываем ссылку на нужную анимацию из библиотеки;
- Стараемся не перегружать интерфейс лишними анимациями
Формат передачи анимаций в макетах:
Для анимаций на платформах Web и Flutter мы используем Rive или Lottie. Поддерживаются файлы форматов .riv и .json.
Если анимация простая, её можно сделать в Figma с помощью Smart Animate.
Если анимация сложная, нужно предоставить краткое описание и референс (для Web) или ссылку на готовую анимацию из библиотеки (для Flutter).
Частые ошибки
Во избежание недопонимания и сбоев на этапе разработки мы обращаем внимание на следующие типовые ошибки:
– Неупорядоченные слои (например: Rectangle 234, Group 12);
– Отсутствие комментариев к неочевидным элементам интерфейса;
– Дублирование компонентов в UI-Kit;
– Размытые изображения с разрешением ниже 72 DPI;
– Пропущенные этапы прототипирования, информационной архитектуры и построения User Flow.
Финальная проверка
Перед тем как передать макеты разработчикам, мы обязательно проверяем их по чек-листу, чтобы ничего не упустить:
- Указаны все состояния экранов.
- Все компоненты из UI-Kit;
- Стрелки переходов между экранами;
- Комментарии к сложным элементам;
- Тег статуса "Готово к разработке";
- Проверена адаптивность дизайна.
Заключение
Упорядоченная система в дизайн-процессе предрасполагает не только к продуктивной коммуникации в команде, но и к скорости передачи макетов заказчику. А также экономии бюджета разработки.
В следующих материалах по дизайну, мы покажем как мы оптимизируем коммуникацию с заказчиком.
