Передача дизайна в разработку: как подготовить макеты и не потерять детали

Коротко: передача дизайна в разработку (design handoff) — это не отправка ссылки на Figma, а процесс, в котором дизайнер отдаёт команде всё, что нужно для реализации без догадок: упорядоченный файл, токены вместо сырых значений, компоненты со всеми состояниями, поведение на разных ширинах, граничные случаи, тексты и ассеты. Начинается он задолго до финального макета, а заканчивается дизайн-ревью собранного интерфейса. Хорошая подготовка занимает несколько часов и экономит дни переписки и переделок.

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

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

Что такое передача дизайна в разработку?

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

В хорошей передаче три слоя:

• Что выглядит как. Макеты экранов, сетка, отступы, типографика, цвета, иконки и изображения — всё, что видно глазом.
• Что ведёт себя как. Состояния элементов, переходы, анимации, адаптивность, валидация форм, загрузка данных, ошибки и пустые экраны.
• Почему именно так. Контекст решений: какую задачу пользователя закрывает экран, что важно сохранить, где допустим компромисс. Без этого слоя разработчик не может принять разумное решение в ситуации, которую макет не предусмотрел.

Первый слой Figma передаёт почти автоматически. Второй и третий — нет, и именно там происходят основные потери.

Почему макеты теряются по дороге в код?

Расхождение между дизайном и реализацией редко бывает чьей-то небрежностью. Обычно у него системные причины.

• Макет показывает только счастливый путь. Нарисован экран с идеальными данными: имя в одну строку, три товара в корзине, всё загрузилось. Что делать с именем в 40 символов, пустой корзиной и ошибкой сервера, разработчик решает сам.
• Сырые значения вместо системы. В макете цвет #5B4FD6 и отступ 23 пикселя, а в коде уже есть токены color.accent и space.6. Разработчик подбирает ближайшее, и через десять экранов интерфейс «плывёт».
• Отрисованы три ширины, а экранов — бесконечно много. Между 390 и 1440 пикселями сотни промежуточных состояний, и правила перестройки сетки никто не описал.
• Компоненты отвязаны от библиотеки. Кнопку скопировали и поправили вручную, и она перестала быть кнопкой из дизайн-системы. В коде появляется ещё один вариант.
• Решения живут в головах и чатах. Договорились голосом, что модальное окно закрывается по клику вне него, но в файле этого нет. Через месяц никто не помнит.
• Файл продолжает меняться. Дизайнер правит макет после передачи, разработчик верстает по старой версии, и непонятно, какая актуальна.

Каждая из этих причин закрывается конкретной практикой. Дальше — по порядку.

Когда начинать передачу?

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

Рабочая схема выглядит так:

1. На этапе структуры и прототипа разработчик смотрит сценарии и оценивает сложные места: интеграции, тяжёлые таблицы, нестандартные анимации. Подробно об этом этапе мы писали в материале о прототипировании сайта.
2. По мере готовности макетов экраны передаются порциями — по сценариям или фичам, а не всем проектом за раз. Так вопросы приходят, пока дизайнер ещё в контексте.
3. Перед стартом спринта проходит встреча передачи: дизайнер ведёт по сценарию, разработчики задают вопросы, ответы фиксируются в файле.
4. Во время разработки работает канал быстрых вопросов, а дизайнер доступен для коротких решений.
5. После сборки проходит дизайн-ревью на стенде, и только потом задача считается закрытой.

Такой подход превращает передачу из события в поток. Он особенно важен, когда сроки сжаты: порционная передача позволяет начинать разработку раньше, не дожидаясь всего дизайна.

Как подготовить файл Figma к передаче?

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

Страницы и статусы

• Отделите рабочие страницы от передаваемых: «Черновики», «На ревью», «Готово к разработке», «Архив». Разработчик смотрит только последнюю актуальную.
• Группируйте экраны по сценариям, а не по порядку рисования: «Регистрация», «Оформление заказа», «Профиль».
• Отмечайте статус каждого раздела. В Dev Mode для этого есть пометка Ready for dev, в обычном режиме — секции с понятными названиями.
• Называйте фреймы по смыслу: «Корзина — пустая», «Корзина — ошибка оплаты», а не «Frame 284».

Слои и компоненты

• Используйте компоненты из библиотеки и не отвязывайте экземпляры. Если нужен новый вариант — добавьте его в библиотеку или явно пометьте как кастомный с описанием.
• Стройте раскладку на Auto Layout: тогда отступы и поведение при изменении контента читаются прямо из файла и совпадают с флексбоксом в коде.
• Удалите скрытые слои, лишние группы и пустые фреймы. Чем меньше вложенности, тем проще найти нужный элемент.
• Держите размеры целыми и кратными шагу вашей сетки — подробнее о системе отступов в статье про сетку 4/8 pt.

Токены вместо значений

Цвета, типографика, отступы, радиусы и тени должны быть переменными и стилями, а не числами. Называйте их по роли, а не по виду: color.background.surface вместо gray-50. Тогда в Dev Mode разработчик видит имя токена, который уже есть в коде, и не подбирает похожий оттенок. Как выстроить уровни примитивов, семантики и компонентов, мы разбирали в гайде по дизайн-токенам, а общий формат обмена токенами между инструментами описывает W3C Design Tokens Community Group.

Что обязательно передать разработчику?

Набор зависит от проекта, но ядро одинаково для сайта, веб-сервиса и мобильного приложения.

1. Все экраны сценария на ключевых ширинах. Обычно это мобильная, планшетная и десктопная версии. Для приложений — с учётом безопасных зон, клавиатуры и системных панелей.
2. Состояния компонентов. Обычное, наведение, нажатие, фокус, неактивное, загрузка, ошибка, успех. Полный перечень с требованиями доступности — в нашем чек-листе состояний компонента.
3. Состояния экранов. Первая загрузка, скелетоны, пустой список, ничего не найдено, нет сети, нет прав доступа, ошибка сервера.
4. Граничные случаи контента. Длинные имена и заголовки, одна и сто позиций в списке, отсутствующее изображение, большие числа, разные валюты и форматы дат.
5. Формы целиком. Обязательные поля, правила валидации, тексты ошибок, маски, момент проверки, поведение кнопки отправки.
6. Финальные тексты. Заголовки, подписи кнопок, сообщения об ошибках и пустых состояниях. «Lorem ipsum» в передаваемом макете — гарантированная переделка.
7. Ассеты. Иконки в SVG, изображения в нужных размерах и форматах, правила кадрирования, альтернативные тексты для значимых картинок.
8. Анимации. Длительность, кривая, что именно анимируется, поведение при включённом prefers-reduced-motion. Для сложной анимации — видео-референс или Lottie-файл.
9. Требования доступности. Порядок фокуса, подписи для экранных дикторов, контраст, размер целей касания. Ориентир — критерии WCAG 2.2; на практике о контрасте и фокусе мы писали в разборе WCAG 2.2.
10. Данные и интеграции. Что на экране статично, а что приходит из API, какие поля обязательны в ответе, что показывать, если данные не пришли.

Как описать поведение, а не только внешний вид?

Статичный макет не может показать, как интерфейс реагирует на действия и меняющиеся условия. Это задача аннотаций — коротких пометок прямо рядом с экранами.

Аннотируйте намерение

Пометка «отступ 24» бесполезна: его и так видно в Dev Mode. Полезна пометка о том, что неочевидно из картинки: «список сортируется по дате, новые сверху», «кнопка неактивна, пока не заполнены обязательные поля», «при ошибке оплаты пользователь остаётся на шаге и видит сообщение над формой, введённые данные сохраняются». Пишите о правилах, а не о пикселях.

Опишите адаптивность словами

Три отрисованных ширины не объясняют, что происходит между ними. Добавьте правила:

• на каких ширинах перестраивается сетка и сколько в ней колонок;
• какие блоки растягиваются, а какие имеют максимальную ширину;
• что прячется, сворачивается или переезжает в другое место на узком экране;
• как ведут себя длинные тексты — переносятся, обрезаются с многоточием или сворачиваются.

Покажите переходы

Для сценариев с несколькими шагами соберите кликабельный прототип или хотя бы схему переходов со стрелками. Разработчику важно видеть, откуда пользователь пришёл на экран, куда уходит и что происходит при возврате назад: сохраняются ли введённые данные, сбрасывается ли прокрутка.

Какие инструменты помогают при передаче?

Инструменты не заменяют порядок в файле, но заметно сокращают ручную работу.

• Figma Dev Mode. Отдельный режим для разработчиков: показывает имена переменных вместо сырых значений, CSS и код для iOS и Android, статус Ready for dev, сравнение изменений между версиями и аннотации с измерениями. Подробности — в руководстве Figma по Dev Mode.
• Code Connect. Связывает компоненты Figma с реальными компонентами в репозитории. Разработчик видит не сгенерированный CSS, а готовый вызов компонента из кодовой базы со своими свойствами.
• Синхронизация токенов. Плагины и скрипты выгружают переменные из Figma в JSON, а оттуда — в CSS-переменные и платформенные ресурсы. Так цвет меняется в одном месте и доезжает до кода без ручного переноса.
• ИИ-генерация кода из макета. Генераторы и агенты через MCP-сервер Figma читают структуру файла и собирают вёрстку. Качество результата напрямую зависит от того, насколько файл чистый: осмысленные имена слоёв, компоненты из библиотеки, Auto Layout и семантические токены. О том, как Figma учит агента работать по правилам дизайн-системы, мы писали в отдельном материале.
• Трекер задач. Каждая задача ссылается на конкретный фрейм или секцию, а не на файл целиком. Так разработчик открывает ровно то, что нужно, и видит актуальную версию.

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

Как провести встречу передачи и дизайн-ревью?

Встреча передачи

Даже идеальный файл стоит пройти голосом. Встреча на 30–60 минут перед стартом работ снимает большую часть будущих вопросов.

1. Дизайнер коротко напоминает задачу пользователя и цель фичи.
2. Проходит сценарий по экранам — от входа до результата, включая ошибки и пустые состояния.
3. Отдельно показывает новые компоненты и места, где дизайн отступает от системы.
4. Разработчики задают вопросы и называют технически сложные места.
5. Все решения записываются в файл комментариями или аннотациями — не в чат и не в память.

Дизайн-ревью собранного интерфейса

Задача не закрыта, пока дизайнер не посмотрел результат на стенде. Ревью удобно проводить по фиксированному списку:

• сетка, отступы и типографика совпадают с макетом на всех ключевых ширинах и между ними;
• все состояния компонентов на месте, включая фокус с клавиатуры;
• пустые, ошибочные и загрузочные экраны отрабатывают, как задумано;
• длинные тексты и нестандартные данные не ломают раскладку;
• анимации соответствуют описанию и отключаются при prefers-reduced-motion;
• контраст и размеры целей касания проходят проверку.

Замечания оформляйте задачами с приоритетом: что блокирует релиз, что можно поправить следующей итерацией. Отличия «на пиксель» без влияния на восприятие лучше не превращать в бесконечный цикл правок. Для быстрой оценки готового экрана подойдёт и метод из статьи про UX-аудит за 30 минут.

Типичные ошибки передачи

1. Ссылка вместо передачи. «Вот Figma, там всё есть» — и разработчик неделю разбирается, какая страница актуальна.
2. Правки после передачи без уведомления. Макет изменился, задача — нет. Любое изменение после статуса «готово к разработке» должно сопровождаться пометкой и сообщением.
3. Только десктоп. Мобильная версия придумывается разработчиком по ходу вёрстки, и решения в ней случайные.
4. Нет состояний. Кнопка без фокуса, поле без ошибки, список без пустого экрана — каждый пропуск разработчик закроет по-своему.
5. Детали, которые невозможно реализовать. Эффект, который требует тяжёлой библиотеки ради одного экрана, или раскладка, ломающаяся на реальных данных. Ловится ранним участием разработчика.
6. Разные названия для одного и того же. В макете «карточка», в коде Tile, в трекере «плитка». Договоритесь о едином словаре компонентов.
7. Нет владельца решений. Когда разработчику не у кого спросить, он выбирает сам — и не всегда так, как выбрал бы дизайнер.

Чек-лист передачи дизайна в разработку

Скопируйте его в шаблон задачи и отмечайте перед статусом «готово к разработке»:

• экраны лежат на странице «Готово к разработке», фреймы названы по смыслу;
• ссылка в задаче ведёт на конкретную секцию или фрейм;
• все цвета, шрифты, отступы и радиусы — токены и стили из библиотеки;
• компоненты не отвязаны, кастомные варианты описаны;
• есть мобильная, планшетная и десктопная версии, правила перестройки описаны словами;
• отрисованы все состояния компонентов, включая фокус и неактивное;
• отрисованы пустые, загрузочные и ошибочные состояния экранов;
• проверены граничные случаи контента: длинные тексты, нет данных, много данных;
• формы содержат правила валидации и тексты ошибок;
• в макетах финальные тексты, а не «рыба»;
• иконки и изображения готовы к экспорту, у значимых картинок есть альтернативный текст;
• анимации описаны: длительность, кривая, поведение при уменьшении движения;
• указаны порядок фокуса, контраст и подписи для экранных дикторов;
• отмечено, какие данные приходят из API и что показывать при их отсутствии;
• проведена встреча передачи, решения записаны в файл;
• назначена дата дизайн-ревью на стенде.

Если все пункты отмечены, разработчик тратит время на код, а не на расшифровку макета. А дизайн-ревью превращается из поиска расхождений в короткую сверку.

Редакция Флагштока

Пишем об UX/UI-дизайне: исследования, интерфейсы, дизайн-системы и доступность.