Чек-лист design handoff: что требовать от макета, чтобы не переделывать вёрстку

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

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

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

Почему передача макета ломается на стыке дизайна и кода

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

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

Что обязательно передавать вместе с макетом, кроме самого файла

Файл с артбордами — только половина handoff. Без трёх вещей ниже разработчик вынужден гадать или писать дизайнеру за каждым значением.

Спецификации и отступы (redline/spec)

Спецификация (redline, спек) — зафиксированные числовые значения отступов, размеров шрифта, толщины рамок и радиусов скругления, а не оценка «на глаз». В Figma это закрывает Dev Mode: он показывает точные CSS-свойства при клике на элемент, без ручного вымеривания линейкой по макету.

Токены и переменные (цвет, типографика, радиусы)

Токен — именованное значение («primary-500», «radius-md»), а не голый HEX-код или число пикселей, зашитое в конкретный компонент. Если макет использует токены, правка цвета бренда или базового отступа происходит в одном месте и автоматически применяется ко всем компонентам — без ручного поиска по коду.

Экспортированные ассеты (иконки, изображения, SVG)

Иконки и декоративная графика передаются готовыми файлами в векторе (SVG), а не скриншотом из макета или «найдите похожую в интернете». Отдельно стоит уточнить соглашение по именованию файлов — на крупном проекте десятки иконок с именами вроде «иконка 2 финал» быстро превращаются в проблему для всей команды.

Брейкпоинты и адаптивные размеры — где обычно теряются данные

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

Минимум брейкпоинтов, который стоит требовать явно: десктоп (от ~1280px), планшет (~768–1024px) и мобильный (~360–430px) — с реальным поведением сетки на каждом, а не пропорциональным уменьшением одного макета. Отдельно проверьте пограничные значения — что происходит ровно на границе брейкпоинта, а не только в его середине.

Состояния компонентов, которые забывают нарисовать

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

Пустые состояния (empty state)

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

Ошибки и edge-кейсы (error state, overflow текста, длинные строки)

Сообщение об ошибке запроса, превышение лимита символов в поле, имя из 40 символов в карточке на 120px шириной — всё это должно быть нарисовано хотя бы в одном варианте, а не оставлено на усмотрение разработчика в момент вёрстки.

Hover/focus/disabled для интерактивных элементов

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

Структура слоёв и именование — почему это не «дизайнерский перфекционизм»

Слой с именем «Rectangle 47 copy 3» ничего не сообщает о назначении элемента, и в Dev Mode такое имя попадает прямо в сгенерированный CSS-класс. Осмысленная структура слоёв («header/nav/menu-item») — не эстетика ради эстетики, а часть технической документации, которая экономит время при каждой правке. Компонент из плоского списка в двадцать несгруппированных слоёв читается разработчиком в разы дольше компонента, разложенного по логическим группам с понятной вложенностью.

Анимация и переходы: что фиксировать в макете, чтобы не угадывать на вёрстке

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

Синхронизация перед стартом: что обсудить на созвоне, а не в комментариях к макету

Часть вопросов решается быстрее голосом, чем перепиской в комментариях к макету, где ответ дизайнера может прийти через день. На коротком созвоне перед стартом реализации стоит закрыть: какие компоненты уже есть в проекте и их нужно переиспользовать, а не верстать заново; какие брейкпоинты и состояния точно есть, а какие дизайнер сознательно оставил на решение разработчика; и какие элементы условны (placeholder-контент), а какие — финальный текст. Такой созвон занимает 20–30 минут, но закрывает половину вопросов, которые иначе растянутся на дни переписки уже после старта вёрстки.

Как проверить, что вёрстка соответствует макету

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

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

Расширенный разбор этапов передачи макета с примерами «правильно/неправильно» и готовым нумерованным чек-листом можно посмотреть в материале «Экономим нервные клетки: как передавать макеты в разработку» на Хабре.