Передача макета в разработку: как упростить процесс с помощью ИИ

«Сверстали не так» — знакомо? После этой фразы дизайнер с разработчиком неделю переписываются в комментах и выясняют, кто прав. Скажу честно: чаще всего виноват не разработчик. В макете просто не было стейтов, адаптива и переменных, и он додумал всё сам)

А в 2026 году у макета появился ещё один читатель — ИИ-агент. И вот он уже ничего додумывать не будет: сделает ровно то, что увидит. Поэтому передача макета в разработку теперь — это подготовка файла сразу под двоих, под человека и под нейронку.

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

Если по-простому, передача макета в разработку — это момент, когда дизайн превращается в задачу для разработчика. Плюс всё, что к нему прилагается: файл, ассеты, описание логики. В вакансиях это называют хендофф (от английского handoff — «передача»). Слово модное, суть простая: отдать дизайн так, чтобы его собрали без потерь.

Макет ≠ сайт почти всегда по четырём причинам:

1. Нет стейтов. Как выглядит кнопка при наведении, поле с ошибкой, пустой экран, загрузка — разработчик не знает и рисует сам.
2. Цвета и отступы «на глаз». Если в макете 15, 16 и 17 пикселей там, где должно быть одно значение, в коде их тоже будет три.
3. Нет адаптива. Есть только десктоп, а мобилку разработчик собирает «по вкусу».
4. Нет контекста. Непонятно, зачем этот экран, куда ведёт кнопка и что в нём важно сохранить.

ИИ эти проблемы не решает, а усиливает. Разработчик хотя бы спросит. Агент возьмёт то, что есть, и очень уверенно сверстает с ошибкой)

Я сам долго недооценивал эту часть. Макеты вроде чистые, логика есть, всё понятно. Но когда начал сам верстать на Webflow и Taptop, понял, насколько дико ошибался. Начинаешь понимать, как каждый элемент поведёт себя на вёрстке, и перестаёшь придумывать решения, которые увеличат стоимость разработки в 2 раза.

Коротко пробежимся по хронологии, без пересказа релизов:

• 2023–2024 — Dev Mode в Figma. Отдельный режим для разработчиков: инспектор, статус «Ready for dev», сравнение версий.
• Май 2025 — Figma MCP. Claude Code, Cursor и другие агенты начинают получать данные макета напрямую: структуру, переменные, компоненты, скриншот.
• Сентябрь 2025 — удалённый MCP. Больше не нужно держать открытым десктопное приложение Figma.
• Март 2026 — запись на холст. Агент уже не только читает макет, но и сам вносит в него изменения.
• Июнь 2026 — Figma Motion. Анимацию из макета можно отдать агенту сразу кодом. Для тех, кто страдал с описанием анимаций, — кайф)

По факту передача перестала быть историей «скинул ссылку и созвонились». Теперь макет — это данные: структура, переменные, компоненты.

И одна цифра, чтобы не улетать в облака. По отчёту Figma за 2025 год, 78% дизайнеров и разработчиков говорят, что ИИ ускоряет работу, но полагаться на результат могут только 32%. Вся эта разница — качество макета на входе.

Порядок в файле — первое, что видит разработчик, и первое, что считывает агент. На собесах, кстати, это тоже спрашивают: «Как вы организуете макет?» И хотят увидеть вылизанный файл, а не помойку из 300 фреймов.

• Страницы. Cover / Design / Components / Assets / Archive. Всё финальное помечаем «Ready for dev», черновики уносим в архив. Разработчику не нужно лазить по вашим 15 вариантам хедера)
• Нейминг слоёв. Никаких «Frame 1234» и «Rectangle 56». Агент берёт имя слоя и делает из него компонент в коде: из Button/Primary/Hover выйдет нормальный компонент, а из «Frame 482» — мусор.
• Лейауты везде. Из автолейаута получаются flex и grid. Из «свободных» фреймов — абсолютное позиционирование и магические числа, за которые вам потом скажут спасибо (нет).
• Компоненты. Повторяется больше одного раза — значит, компонент. Варианты собираем в наборы со свойствами (size, state, type), отвязанных инстансов на макете быть не должно.
• Чистота. Пустые и скрытые слои удаляем, тексты ставим финальные. Lorem ipsum и «Heading 1» в макете на сдачу — это прям красный флаг.

Проверку порядка спокойно можно отдать ИИ. Через Figma MCP агент пройдётся по фрейму и выдаст список косяков. Пример запроса:

Найди в этом фрейме слои без автолейаута, слои с именами по умолчанию и цвета без переменных — выведи списком.

Без них вообще никуда. Дизайн-токены — это цвета, отступы, радиусы и кегли, у которых есть имя, а не просто число. Не #2F6BFF, а accent/primary. Не 24 пикселя, а space/l.

Пример из жизни. Цвет кнопки в макете задан как #2F6BFF. Разработчик хотя бы спросит, что это за цвет. Агент не спросит: вставит #2F6BFF прямо в код. Через месяц бренд-цвет поменяется в дизайн-системе, а на кнопке останется старый. Ну и удачи потом искать его по всему проекту)

Что завести перед передачей:

• цвета в Variables, сгруппированные по назначению: фон, поверхность, обводка, текст, акцент, статусы;
• типографику стилями (H1–H6, основной текст, подписи) с размером, интерлиньяжем, трекингом и весом;
• отступы, радиусы и ширину контейнера — тоже переменными.

Лайфхак: дизайн-систему можно сначала накидать в Claude Code, а потом перенести в Figma. Я так делал на одном из проектов — немного доработал руками и потратил минимум времени.

Тут важно не перегнуть палку. Рисовать каждый стейт и три брейкпоинта нужно далеко не везде.

Шаблонный проект — типовой лендос, сайт на конструкторе — вполне закроет база: десктоп, мобилка и основные состояния кнопок и форм. Остальное разработчик соберёт по правилам дизайн-системы, и это оптимальная история.

А вот сложный продукт или кастомный промо-лендинг с нестандартной вёрсткой и анимациями — тут уже обязательно:

• Адаптив: каждая страница в трёх брейкпоинтах (у меня 1600 / 768 / 375), мобильное меню в открытом и закрытом виде, зоны касания не меньше 44 × 44.
• Стейты: кнопки и ссылки (обычное состояние и ховер), поля ввода, формы — пустая, заполненная, отправка, успех, ошибка сервера; чекбоксы, свитчеры, дропдауны.
• Edge cases: длинный заголовок, нет картинки, одна карточка вместо трёх, пустой экран, скелетон загрузки, «ничего не найдено».
• Анимации: разложены по кадрам (начало, промежуточные шаги, конец) или есть видео-референс. Отдельно описано, что происходит на телефоне.

ИИ тут хорош как ревьюер. Попросите: «Перечисли недостающие состояния и edge cases для этого экрана», и он найдёт то, что вы пропустили. А если совсем лень, то можно отдать и отрисовку. Мне как-то было лень прорабатывать все состояния кнопок в дизайн-системе, и я попросил Figma Agent собрать основные стейты не только для кнопок, но и для других компонентов)

Лично я топлю за связку Claude Code + Figma MCP. Последние полгода я работаю с Клодом чуть ли не половину рабочего дня, и для подготовки и сдачи макета этого хватает с головой.

Как это выглядит по шагам:

1. Подключаем MCP. Одна команда: claude mcp add --transport http figma https://mcp.figma.com/mcp. В Cursor то же самое через настройки, ничего сложного.
2. Пишем правила для агента в CLAUDE.md в репозитории: компоненты только из дизайн-системы, только токены, никаких новых иконпаков, брейкпоинты проекта. Черновик правил может сгенерировать сама Figma, дальше докручиваете под себя.
3. Даём ссылку на конкретный фрейм, а не на весь файл. С размытым запросом агент работает хуже и быстрее съедает лимиты.
4. Агент читает макет — структуру, переменные, скриншот — и собирает спецификацию: страницы и блоки, поведение интерактивов, логику форм, события аналитики, куда ведёт каждая кнопка. То, что раньше писалось руками полдня.
5. Сверяем. Скриншот вёрстки против скриншота макета на нескольких ширинах.
6. Финальное ревью — человеком. Дизайнер смотрит глазами, разработчик — код. Тут без вариантов.

Третий элемент связки — Notion MCP. У меня в Notion лежат два шаблона чек-листов: сдача дизайна и сдача разработки. Через MCP агент держит их под рукой: проходится по пунктам, отмечает выполненные и показывает, что осталось. В итоге чек-лист перестаёт быть документом, который все забывают открыть)

Ещё один момент. Перед показом клиенту я гоняю макет через своего агента «дизайн-аудит». Его задача не оценивать мои решения, а сверить всё строго по ТЗ, брифу и смыслам и найти недочёты в тексте (которые иногда прилетают и от клиента).

По факту для большинства задач хватает первых двух строк. Остальное — по ситуации.

Отдельно про лимиты MCP. На месте с правом просмотра (View или Collab) у вас всего 20 вызовов в месяц на любом тарифе. На месте Dev или Full в тарифе Professional — 200 в день. Так что для регулярной работы нужно платное место.

Даже если дать агенту абсолютно всё — переменные, компоненты, правила, — на старте он всё равно будет ошибаться. Чаще всего путает переменные: подставляет близкое значение или берёт число вместо токена.

Поэтому первые задачи курируем: смотрим каждый результат, находим ошибку, дописываем правило, которое её закрывает. Типичные пары «ошибка → страховка»:

• hex и пиксели вместо токенов → переменные в макете плюс правило «только токены» в CLAUDE.md;
• нет адаптива → фреймы под каждый брейкпоинт или явное правило в макете;
• весь экран одним файлом → правило «разбивать на компоненты и переиспользовать существующие»;
• кончились лимиты → передаём фрейм, а не файл целиком;
• конфиденциальность → проекты под NDA не отдаём во внешние модели без согласия клиента.

Хорошая новость: если один раз всё правильно ему разложить, дальше он с этим вряд ли ошибётся. Время на кураторство окупается уже на втором-третьем макете. Сначала ты учишь агента, потом агент экономит тебе часы — нормальный обмен)

Фундамент

1. Цвета заведены в Variables и сгруппированы по назначению.
2. Типографика оформлена стилями: размер, интерлиньяж, трекинг, вес.
3. Отступы, радиусы и ширина контейнера — переменными.
4. Шрифты с лицензией, файлы шрифтов лежат отдельно.

Компоненты и порядок

5. Всё, что повторяется, вынесено в компоненты; варианты собраны в наборы.
6. Компоненты на лейаутах, отвязанных инстансов нет.
7. Слои названы осмысленно, без «Frame 1234».
8. Страницы: Cover / Design / Components / Assets / Archive; финальные экраны помечены «Ready for dev».
9. Тексты финальные, без lorem ipsum.

Адаптив и поведение

10. Каждая страница в трёх брейкпоинтах, есть мобильное меню.
11. Стейты кнопок, ссылок, полей и форм, включая отправку, успех и ошибку.
12. Пустые экраны, загрузка и граничные случаи.
13. Анимации разложены по кадрам или есть видео-референс.

Ассеты и служебное

14. Фото выгружены в 2x с понятными именами, иконки — в SVG на одной сетке.
15. Есть страница 404, favicon и OG-картинка 1200 × 630.

Спецификация и ИИ

16. Описаны страницы, блоки и логика интерактивов.
17. Логика форм: обязательные поля, валидация, куда уходят данные.
18. Список событий аналитики и карта ссылок.
19. Правила для агента лежат в репозитории, ссылка ведёт на конкретный фрейм.
20. После вёрстки — сверка скриншотами и финальное ревью человеком.

Если хотите разобрать передачу макета на своём проекте и понять, что из рутины уже сейчас можно отдать агенту, — пишите, разберём на консультации по ИИ-пайплайну)