Из макета в прод: как дизайн передаётся разработке в реальных проектах

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

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

Почему передача дизайна — это отдельный этап, а не формальность

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

• разные браузеры и устройства;
• ограничения CMS, фреймворка или дизайн-системы;
• динамический контент, который невозможно предсказать на 100%;
• сроки, бюджет и технический долг;
• необходимость поддерживать продукт после релиза.

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

Что на самом деле нужно разработчику

Разработчику важны не только пиксели. Ему нужны ответы на вопросы:

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

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

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

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

Минимальный набор перед релизом

• Основной экран и все ключевые состояния.
• Адаптивы для основных разрешений.
• Сетка, отступы, типографика, цвета, иконки.
• Интерактивные состояния: hover, active, focus, disabled, error, success.
• Пустые, загрузочные и ошибочные состояния, если они уместны.
• Компоненты, собранные по принципам повторного использования.
• Логика поведения сложных блоков.
• Комментарии к нестандартным решениям.

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

Что лучше не оставлять на потом

• «Придумать по ходу, как это будет работать».
• «Потом дорисуем мобильную версию».
• «Тут и так понятно, что имелось в виду».
• «Это же очевидный hover».
• «Второй экран не нужен, там всё по аналогии».

Именно такие фразы чаще всего приводят к разъезжающейся реализации. По опыту, каждый раз, когда команда откладывает решение «на потом», это «потом» превращается в аврал за день до релиза. Лучше потратить час на проработку сейчас, чем день на переделку потом.

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

Хороший процесс передачи можно разложить на несколько этапов. В нашем агентстве мы придерживаемся именно такой последовательности — она выкристаллизовалась из десятков проектов и позволяет минимизировать недопонимание.

1. Финальная проверка макета

Перед тем как идти к разработке, дизайнер проверяет:

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

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

2. Подготовка спецификации

Спецификация — это не отдельная простыня текста, а понятный набор пояснений. В неё обычно входят:

• названия экранов и компонентов;
• размеры и поведение элементов;
• правила адаптива;
• состояния элементов;
• требования к анимации;
• ограничения и исключения;
• ссылки на источники контента, если они есть.

Хорошая спецификация экономит часы обсуждений. Я обычно оформляю её прямо в Figma — на отдельной странице или в виде комментариев к ключевым фреймам. Так разработчик видит пояснения в контексте, а не в отрыве от макета.

3. Структурирование файла

Удобнее всего, когда файл организован не хаотично, а логично:

• отдельные страницы под экраны;
• отдельные страницы под компоненты;
• отдельная страница с описанием;
• единые названия слоёв и компонентов;
• без мусора, старых вариантов и лишних артефактов.

Чем чище структура, тем быстрее разработчик ориентируется в макете. Это не эстетика, а чистая прагматика: когда в файле 50 фреймов с названиями вроде «Frame 147», поиск нужного экрана превращается в квест.

4. Передача на созвон или в тикет

В идеале передача не ограничивается ссылкой на файл. Нужен короткий синк с разработкой или подробный комментарий в задаче:

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

Синк не обязательно должен быть долгим. Часто хватает 15–20 минут, чтобы пройтись по ключевым моментам и снять 80% будущих вопросов. Это инвестиция времени, которая окупается отсутствием бесконечных уточнений в чате.

5. Контроль реализации

После старта верстки дизайн не исчезает из процесса. Его нужно проверять на нескольких точках:

• после первичной сборки;
• после адаптива;
• после подключения реального контента;
• перед финальным релизом.

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

Что обязательно передавать вместе с дизайном

Ниже — практический чек-лист для передачи макета в разработку. Эту таблицу мы используем как памятку для дизайнеров перед handoff-встречей.

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

Какие артефакты нужны на стороне дизайна

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

Дизайн-система или UI-kit

Это набор повторяемых компонентов: кнопки, поля, карточки, меню, модалки, табы. Чем лучше он собран, тем проще разработке.

Плюсы:

• меньше ручной работы;
• легче масштабировать проект;
• проще поддерживать консистентность.

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

Прототип поведения

Если есть сложные сценарии, лучше показать их в интерактивном прототипе:

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

Прототип не обязан быть детальным. Достаточно связать ключевые фреймы в Figma, чтобы разработчик увидел последовательность взаимодействия. Это снимает кучу вопросов типа «а что должно произойти после клика сюда».

Технические пояснения

Иногда важно уточнить:

• компонент должен быть статичным или динамическим;
• данные приходят из API или фиксированы;
• блок может скрываться при отсутствии контента;
• есть ли ограничения по длине заголовка;
• допускается ли перенос текста в две строки.

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

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

За годы работы я собрал целую коллекцию повторяющихся ошибок. Вот те, что встречаются чаще всего.

1. Макет без состояний

На экране всё красиво, но нет hover, error, empty state и loading. В итоге разработка додумывает поведение сама. Результат: при наведении кнопка становится неестественного оттенка, ошибка выглядит как системное сообщение, а пустой экран — как баг.

2. Неучтённый адаптив

Частая ошибка — делать только desktop и надеяться, что мобильная версия «как-нибудь упростится». В реальности упростится не всегда, а иногда и наоборот станет сложнее. Особенно это касается таблиц, сложных сеток и фильтров — на мобильном они требуют принципиально другого подхода.

3. Неясные приоритеты

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

4. Слишком много уникальных решений

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

5. Отсутствие владельца решения

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

Как дизайнеру и разработчику работать без конфликтов

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

Полезные правила для команды

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

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

Что помогает ускорить работу

• Общий язык между дизайном и разработкой.
• Готовая библиотека компонентов.
• Минимум уникальных исключений.
• Прозрачный список допущений.
• Короткие синки по сложным экранам.

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

Как передавать адаптивы, чтобы не потерять логику

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

Что обязательно фиксировать

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

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

Практический совет

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

Контроль качества после разработки

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

Что проверять в первую очередь

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

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

На что часто не обращают внимание

• переносы строк в длинных заголовках;
• поведение кнопок на узких экранах;
• обрезка текста в карточках;
• различие между true design и браузерным рендерингом;
• разница между «почти похоже» и реально рабочим интерфейсом.

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

Пошаговый чек-лист передачи макета в разработку

1. Проверить финальность макета.
2. Убрать старые версии и лишние экраны.
3. Согласовать адаптивные точки.
4. Подготовить состояния компонентов.
5. Зафиксировать поведение нестандартных блоков.
6. Добавить комментарии к спорным местам.
7. Передать ссылку на макет и спецификацию.
8. Провести короткий бриф с разработкой.
9. Проверить первую сборку.
10. Сверить адаптив и финальные состояния перед релизом.

Этот чек-лист выглядит линейным, но на практике некоторые пункты могут идти параллельно или циклично. Например, после проверки первой сборки часто