Автоматизация передачи макетов и документация состояний данных

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

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

Матрица состояний данных

Верстка часто «едет», а правки копятся из-за того, что дизайнер не описал поведение интерфейса в нетипичных ситуациях. Профессиональное проектирование всегда учитывает Состояний данных (Data States).

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

1. Ideal State (Идеальное): данные загружены полностью, контент умещается в блоки.
2. Empty State (Пустое): экран без данных. Используйте его для онбординга или призыва к действию.
3. Loading State (Загрузка): используйте Skeleton Screens (скелетные экраны), повторяющие структуру контента. Спиннеры — устаревший стандарт.
4. Error State (Ошибка): реакция системы на отсутствие интернета, ошибку 404 или сбой API.
5. Partial State (Частичное): когда данных мало (одна строка в таблице вместо десяти) или они загрузились не полностью.

Автоматизация через Figma Variables и Modes

Не копируйте фреймы для каждого состояния. Используйте Figma Modes: это позволяет создать один «умный» компонент, вид которого переключается в панели слоев.

Пример

Создайте коллекцию ComponentStates. Для переменной Visibility / ErrorBlock задайте значения true или false в разных режимах (Modes):

• Режим Default: ErrorBlock = false, Skeleton = false.
• Режим Loading: ErrorBlock = false, Skeleton = true.
• Режим Error: ErrorBlock = true, Skeleton = false.

В Dev Mode разработчик увидит свойства и переменные именно для выбранного режима. Ему не придется искать нужный макет по всей странице 🧩

Спецификация интерфейса: контракт с разработкой

Спецификация интерфейса — это набор правил взаимодействия, которые нельзя передать скриншотом. Используйте Annotation Kits и Dev Resources, чтобы привязывать документацию из Jira или Storybook прямо к компонентам в Figma.

Антипример

Дизайнер передал макет формы перевода, где отрисованы только поле и кнопка. Проблема: разработчик сам решает, как выглядит ошибка валидации, какой стоит лимит на нажатие кнопки (debounce) и что происходит при нажатии «Назад» во время оплаты. В итоге реализация не соответствует UX-стратегии.

Внедрите стандарт документации, чтобы избежать хаоса:

Элемент спецификации	Что описываем	Инструмент
Logic & Validation	Маски ввода, лимиты, правила валидации.	Figma Dev Notes / Jira
Focus Order	Порядок перехода по элементам через Tab.	Accessibility plugins
Data States	Переключение режимов (Loading, Empty).	Figma Modes & Variables
Handoff Assets	Автовыгрузка иконок и иллюстраций.	Style Dictionary / CDN

Практическое упражнение

Закрепим навыки на примере критического процесса.

Упражнение

Задание: Подготовить Handoff для экрана «Корзина» в мобильном приложении.

1. Создайте основной фрейм корзины в Figma.
2. Через Variables настройте три режима (Modes): Ideal (товары в списке), Empty (пустая корзина с кнопкой перехода в каталог) и Error (ошибка соединения).
3. Добавьте аннотацию: опишите логику кнопки «Оформить», если сумма заказа меньше минимальной (например, 1000 руб.).
4. Настройте Focus Order: пронумеруйте элементы для корректной работы скринридеров.

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

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