«Дизайнер прислал макет, разработчик сверстал, получилось не как в Figma» — главная боль команд, где дизайн и код живут параллельно. Современные инструменты позволяют сократить разрыв до нуля, но требуют дисциплины с обеих сторон. Расскажем, как мы это делаем.
Auto Layout — обязательный минимум
Любой компонент в макете, который попадёт в код, должен быть собран на Auto Layout. Не «нарисован руками», а собран как контейнер с padding, gap, alignment. Только тогда дизайн соответствует тому, как реально работает Flexbox в браузере.
Признак плохого макета: дизайнер сдвигает элементы клавишами стрелок, чтобы выровнять. Признак хорошего: каждый блок — это Frame с Auto Layout, изменение содержимого автоматически перестраивает соседей.
Для разработчика это значит, что вёрстка получается прямым переносом структуры из Figma в JSX без додумывания. Сэкономленное время — 20–30% от верстки.
Variables вместо магических чисел
В Figma 2024 появились Variables — переменные для цветов, отступов, типографики. Они делают то же, что CSS custom properties и Tailwind config: фиксируют дизайн-токены.
Правило: ни один цвет в макете не задаётся «по hex», только через Variable. Ни один размер шрифта — только через Text Style. Это критично для синхронизации с кодом: переменные в Figma экспортируются в JSON, из JSON собирается tailwind.config.ts.
В наших проектах изменение цвета бренда — это правка одной Variable в Figma, push в репозиторий и автоматический pull request на обновление токенов в коде. Полчаса работы вместо двух дней раньше.
Компоненты в Figma зеркалят компоненты в коде
Большая ошибка — рисовать каждую страницу с нуля без переиспользования. Правильный путь: каждый повторяющийся блок (Button, Card, NavItem) — это Component в Figma. Каждое его применение — Instance.
В коде та же иерархия: каждый Component из Figma имеет ровно один React-компонент с тем же именем и теми же variants. Кнопка с Variant size=md, intent=primary — это <Button size="md" intent="primary"> в TSX.
Code Connect — официальный механизм Figma для связи макета и кода. Дизайнер видит сниппет в правой панели Figma, разработчик копирует его одним кликом. Время на «понять, что за компонент» падает до нуля.
Имена слоёв и фреймов
Имя слоя Group 27 copy 4 — преступление. Имя ProductCard / Footer / Price — нормально. У современных линтеров (Tokens Studio, Figma plugins) есть автопроверка имён и структуры.
В команде договариваемся о конвенции: компоненты PascalCase, слои внутри — описательные, никаких служебных «Frame 1». Делает дизайн читаемым через год и помогает разработчику ориентироваться.
Передача макета: что именно даём разработчику
Минимум: ссылка на Figma-файл с правом просмотра, перечень страниц для верстки в порядке приоритета, экспортированные иконки и иллюстрации (SVG, оптимизированные через SVGO), Brand Guidelines на отдельной странице (типографика, отступы, состояния компонентов).
Опционально, но сильно ускоряет: видео с прохождением по интерактиву (для сложных переходов), таблица состояний компонентов (default, hover, focus, disabled, loading, error), список краевых случаев (пустой стейт, длинный текст, отсутствие данных).
Состояния и interaction
Дизайнер показывает только default — разработчик додумывает hover, disabled, loading. Это всегда плохо. Правильно: каждое состояние нарисовано в Figma как Variant того же компонента. Разработчик видит, как должны выглядеть все случаи, и реализует точно.
То же с переходами и анимациями. Если задумано «появление с фейдом 200мс», это либо описано текстом, либо собрано через Smart Animate в прототипе. Без этого появляется 2–3 итерации правок «не так двигается».
Совместная работа в реальном времени
Дизайнер и разработчик в одном Figma-файле — норма, а не исключение. Комментарии прямо на макете, ответы в треде, история изменений. Митинги по принципу «открыли Figma и обсудили» эффективнее переписки в чате.
Раз в неделю — design review: дизайнер проходит по новой ветке кода и сверяет с макетом, разработчик показывает, что не получилось перенести и почему. Расхождения фиксируются и закрываются за один-два дня.
Итого
Передача макета в код — это не разовое действие, а непрерывный процесс. Auto Layout, Variables, компоненты с вариантами, понятные имена и регулярная синхронизация снимают 80% болезненных переделок. Затраченные 10–15% времени дизайнера на дисциплину окупаются 20–30% времени разработчика и качеством финального продукта.
Частые вопросы
Зачем использовать Auto Layout в Figma?
Любой компонент в макете, который попадёт в код, должен быть собран на Auto Layout. Не «нарисован руками», а собран как контейнер с padding, gap, alignment. Только тогда дизайн соответствует тому, как реально работает Flexbox в браузере. Признак плохого макета: дизайнер сдвигает элементы клавишами стрелок, чтобы выровнять. Признак хорошего: каждый блок — это Frame с Auto Layout. Для разработчика это значит, что вёрстка получается прямым переносом структуры из Figma в JSX без додумывания. Экономит 20–30% времени вёрстки.
Что такое Variables в Figma и зачем они нужны?
В Figma 2024 появились Variables — переменные для цветов, отступов, типографики. Они делают то же, что CSS custom properties и Tailwind config: фиксируют дизайн-токены. Правило: ни один цвет в макете не задаётся «по hex», только через Variable. Ни один размер шрифта — только через Text Style. Это критично для синхронизации с кодом: переменные в Figma экспортируются в JSON, из JSON собирается tailwind.config.ts. Изменение цвета бренда — правка одной Variable плюс push.
Как организовать компоненты в Figma чтобы они зеркалили код?
Каждый повторяющийся блок (Button, Card, NavItem) — это Component в Figma. Каждое его применение — Instance. В коде та же иерархия: каждый Component из Figma имеет ровно один React-компонент с тем же именем и теми же variants. Кнопка с Variant size=md, intent=primary — это Button size="md" intent="primary" в TSX. Code Connect — официальный механизм Figma для связи макета и кода. Дизайнер видит сниппет в правой панели Figma, разработчик копирует одним кликом.
Что должно быть в передаче макета разработчику?
Минимум: ссылка на Figma-файл с правом просмотра, перечень страниц в порядке приоритета, экспортированные иконки (SVG, оптимизированные через SVGO), Brand Guidelines на отдельной странице (типографика, отступы, состояния компонентов). Опционально, но сильно ускоряет: видео с прохождением по интерактиву (для сложных переходов), таблица состояний компонентов (default, hover, focus, disabled, loading, error), список краевых случаев (пустой стейт, длинный текст, отсутствие данных). Без этого появляются 2–3 итерации правок.
Как показывать состояния компонентов в Figma?
Дизайнер показывает только default — разработчик додумывает hover, disabled, loading. Это всегда плохо. Правильно: каждое состояние нарисовано в Figma как Variant того же компонента. Разработчик видит, как должны выглядеть все случаи, и реализует точно. То же с переходами и анимациями. Если задумано «появление с фейдом 200мс», это либо описано текстом, либо собрано через Smart Animate в прототипе. Без этого появляется 2–3 итерации правок «не так двигается», что съедает дни разработчика.
Как организовать совместную работу дизайнера и разработчика?
Дизайнер и разработчик в одном Figma-файле — норма, а не исключение. Комментарии прямо на макете, ответы в треде, история изменений. Митинги по принципу «открыли Figma и обсудили» эффективнее переписки в чате. Раз в неделю — design review: дизайнер проходит по новой ветке кода и сверяет с макетом, разработчик показывает, что не получилось перенести и почему. Расхождения фиксируются и закрываются за один-два дня. Без регулярных ревью разрыв между макетом и кодом растёт лавинообразно.