От макета к коду: Figma, передача и работа с ИИ

Передача макета (handoff) — подготовка макета из Figma к вёрстке: названные слои, компоненты, переменные вместо чисел, все состояния и узкий экран.

Как дизайнер видит страницу

Дизайнер работает не в коде, а в инструменте для макетов. Самый распространённый называется Figma; есть открытый аналог Penpot. Принцип у них общий: холст, на нём кадры, в кадрах слои. Хорошо знать несколько слов из их словаря, потому что именно ими макет разговаривает с кодом.

• Кадр (frame). Прямоугольник с содержимым, «экран» или блок. В коде ему соответствует элемент (div, section).
• Автолейаут (auto layout). Кадр, который сам раскладывает детей в строку или столбец с заданным промежутком и отступами. Это почти точно display: flex с gap и padding. У ширины три режима: Hug (по содержимому), Fill (занять всё место, как flex: 1) и Fixed (числом).
• Компонент и варианты. Деталь, которую можно повторять; варианты (основная и второстепенная кнопка, нажатая и обычная) собраны в один компонент с «свойствами». В коде это компонент и его модификаторы.
• Переменные (variables) и режимы (modes). Именованные значения (цвета, числа), у которых бывает несколько определений по режимам: например, светлая и тёмная тема. Figma сама говорит, что на них можно строить дизайн-токены.
• Dev Mode. Рабочее место разработчика в Figma: он видит размеры, свойства слоёв, переменные и код, а дизайнер может пометить макет «готов к разработке».

Нажмите на детали макета ниже: слева то, что поставил дизайнер, справа тот же смысл в CSS. Обратите внимание, что всюду стоят имена токенов, а не числа.

.card {
  display: flex;
  flex-direction: column;
  gap: var(--space-2);
  padding: var(--space-4);
  border-radius: var(--radius-md);
  background: var(--surface-raised);
}

Что нужно разработчику: макет, готовый к передаче

Передача макета (handoff) ломается там, где дизайнер уверен, что «всё же очевидно». Список того, без чего придётся задавать вопросы:

1. Названные слои. Hero/Title, Hero/Action, Cards/Item, а не «Frame 482». По названиям разработчик находит нужное, а ИИ-инструмент получает осмысленные имена.
2. Компоненты, а не копии. Если кнопка нарисована десять раз, а не взята из компонента, то и в коде их будет десять.
3. Переменные вместо случайных значений. Цвет, взятый из переменной color/accent, превращается в var(--action). Цвет, подобранный «пипеткой», превращается в число, которое потом никто не найдёт.
4. Все состояния главных компонентов: наведение, фокус, недоступно, загрузка, ошибка.
5. Узкий экран. Не обязательно рисовать все страницы, но поведение надо описать: что идёт в одну колонку, что скрывается, что превращается в кнопку-меню. Обычно рисуют три кадра: около 375, 768 и 1280 пикселей.
6. Ресурсы. Что отдаётся векторами (значки, логотип: SVG, чёткие на любом экране), а что растром (фотографии: WebP, AVIF или JPEG, в нескольких размерах для разных экранов), и в каких размерах.
7. Настоящие тексты. Макет с «Lorem ipsum» скрывает проблемы: длинные заголовки, пустые поля. Русские подписи обычно длиннее английских.
8. Заметки. Что происходит при нажатии, порядок фокуса, тексты для alt.

Как макет становится кодом

Путей несколько, и все они опираются на токены.

• Вручную. Разработчик смотрит на макет и пишет вёрстку. Самый надёжный путь для маленького сайта.
• Через Dev Mode. Из макета берут код и размеры. С осторожностью: автоматический код любит абсолютные размеры, которых в хорошей вёрстке быть не должно. Вдобавок у Figma есть Code Connect, который связывает компонент макета с настоящим компонентом в коде, чтобы новые детали брали готовое.
• Через токены. Переменные Figma экспортируют в файл токенов (формат DTCG из предыдущего урока), а из него программа вроде Style Dictionary делает CSS. Тогда значения расходятся без ручной работы. Подробнее о файле токенов вы узнали в одиннадцатом уроке.
• С помощью ИИ. Figma предлагает сервер MCP, через который ИИ-агент получает структурированные сведения о макете, чтобы сделать по нему код. Вы встретитесь с такими инструментами в части про ИИ.

Об этом последнем пути стоит сказать честно: ИИ делает вёрстку по макету быстро, но ошибается так же, как человек. Типичные расхождения:

• вместо токена стоит число, скопированное из макета;
• забыто состояние (чаще всего фокус);
• нет версии для узкого экрана;
• цвета «почти те же», а не из переменных.

Поэтому задача, которую вы даёте ИИ, это та же спецификация передачи: чем она полнее, тем меньше правок. А результат всё равно проверяют: по токенам, по состояниям и на узком экране.

Пример из этого учебника

У самого учебника есть дизайн-система, и она устроена именно так. Каталог design/ репозитория содержит токены: они не написаны вручную, а сгенерированы из файла токенов в формате DTCG, который лежит в проекте NoeticEcho. Откуда они взяты и что изменено, записано в файле PROVENANCE.md (ссылка в источниках). Откройте design/tokens.css: вы увидите те же слои, что в прошлом уроке. Базовые значения вроде --ink-100 и --paper-100, смысловые --surface-canvas, --text-primary, --accent-command, и комментарии там, где дизайнер что-то решил: например, почему у цвета для текста отдельная, более светлая ступень, чем у цвета для заливки (потому что на тёмной панели исходный цвет не проходил контраст).

Это как раз то, что вы делаете в практике: решение записано в файле и в имени, а не в голове автора.

Практика

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

Последний раздел заполните после того, как по спецификации будет сделана вёрстка. Если ИИ-инструмента под рукой нет, возьмите любой код (в том числе свой из прошлых уроков) и найдите расхождения со спецификацией: числа вместо токенов, забытые состояния, отсутствие узкого экрана. Умение найти такие расхождения и есть навык, ради которого мы всё это пишем.

Что было не так с 2025 годом

В 2025 году ИИ-инструменты уже делали вёрстку по макету, но без дизайн-системы они брали значения «из картинки»: код получался похожим на макет, а от токенов расходился. Выигрывали команды, у которых макет и код говорили на одном языке токенов, и инструментам было что соблюдать.