Что разработчик хочет от хендоффа на самом деле — и почему большинство дизайнеров это не дают

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

При этом большинство дизайнеров искренне считают, что делают хендофф хорошо. Макеты выложены в Figma, токены есть, в комментариях даже расписаны состояния. Что ещё нужно?

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

## Где на самом деле ломается хендофф

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

Типичные точки разрыва:

• Состояния, которых нет в макете (loading, empty, error, длинный текст, нет данных, оффлайн)
• Поведение при ресайзе, между брейкпоинтами, на нестандартных экранах
• Микровзаимодействия — что делает кнопка после нажатия, как появляется тост, как ведёт себя инпут при фокусе
• Логика валидации и тексты ошибок
• Что является компонентом дизайн-системы, а что — частный случай
• Доступность: фокус, контраст, порядок табуляции, aria-атрибуты

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

## Что разработчик слышит, когда вы говорите «макет готов»

Тут стоит сделать честное упражнение. Возьмите свой последний хендофф и посмотрите на него глазами человека, который видит проект впервые и должен сдать задачу к спринту.

### Чего он ждёт по умолчанию

• Все состояния компонентов в одном месте, не разбросаны по экранам
• Понятно, какие отступы и размеры — из дизайн-системы, а какие — кастом
• Адаптив описан, а не «ну там пропорционально»
• Тексты финальные, а не «Lorem ipsum» и «тут будет описание»
• Иконки приложены в нужном формате, а не нужно вытаскивать из Figma вручную
• Есть ссылка на спеку или тикет, где описана логика, а не только внешний вид

### Чего он точно не хочет

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

## Различие между «дизайн нарисован» и «дизайн готов к разработке»

Это две разные стадии, и их полезно разделять явно — хотя бы для себя.

Дизайн нарисован: визуально решена основная задача, согласован с продактом, выглядит как надо на главном кейсе.

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

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

### Короткий чек перед тем, как кидать ссылку в чат разработки

• Все состояния (default, hover, focus, active, disabled, loading, error, empty) показаны
• Есть пример с длинным текстом и с пустыми данными
• Описаны брейкпоинты или правила адаптива
• Тексты финальные, согласованы с копирайтером/продактом
• Компоненты — из библиотеки, кастомы помечены явно
• Указаны ссылки на связанные тикеты и предыдущие решения
• Понятно, что в этой задаче, а что — в следующей итерации

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

## Рабочий процесс: как довести макет до состояния «можно брать в работу»

Хороший хендофф — это не финальный рывок в пятницу вечером, а отдельная фаза в спринте. У неё своя длительность, свой чек-лист и свой результат. Если относиться к ней как к «ну закину ссылку» — будете каждый раз получать обратно интерфейс, который на 80% ваш и на 20% чей-то ещё.

### Шаг 1. Заморозка скоупа

Перед тем как готовить макет к передаче, явно зафиксируйте: что входит в эту задачу, а что — в следующую. Не в голове, а в комментарии к фрейму или в тикете.

• Какие экраны попадают в спринт
• Какие состояния обязательны, какие — на потом
• Какие компоненты используем как есть, какие меняем
• Что считается «достаточно хорошо» для этой итерации

Без этого вы будете дорисовывать в процессе разработки, а разработчик — переписывать уже готовые куски.

### Шаг 2. Сборка состояний в одном месте

Самая частая ошибка — состояния разбросаны по разным фреймам и экранам. Кнопка hover на одном экране, disabled — на другом, loading вообще нигде. Разработчику нужно собирать пазл.

Соберите все варианты компонента рядом: default, hover, focus, active, disabled, loading, error, success. Если состояние логически невозможно — напишите это явно, чтобы не возникало вопроса «а почему нет».

### Шаг 3. Прогон по edge cases

Возьмите макет и прогоните через сценарии, которые ломают визуал:

• Имя пользователя из 40 символов
• Список из одного элемента и из 200
• Нулевой баланс, отрицательный баланс, очень большой баланс
• Долгая загрузка, обрыв сети, повторный запрос
• Пустое состояние первого входа vs пустое состояние после очистки
• Текст на языке с длинными словами (немецкий, финский) или с RTL

Половина этих случаев в продакшене встречается чаще, чем «идеальный» сценарий из макета.

### Шаг 4. Сверка с дизайн-системой

Перед передачей пройдитесь по компонентам и честно ответьте: это из библиотеки, или я переопределил отступ/цвет/радиус? Если переопределил — пометьте, и решите: это баг макета, осознанное исключение или повод обновить компонент в системе.

Разработчику нужно знать разницу между «возьми Button из библиотеки» и «здесь намеренно кастомный паддинг, не правь».

## Диагностика: как понять, что хендофф плохой, ещё до жалоб

Не обязательно ждать ретро. Есть сигналы, которые видны сразу.

### Признаки, что макет ещё не готов

• В чате разработки больше трёх уточняющих вопросов по одной задаче
• Разработчик присылает скриншот и спрашивает «так?» — значит, в макете этого не было
• В PR появляются значения, которых нет ни в макете, ни в токенах
• На демо вы впервые видите состояние, о котором не подумали
• QA заводит баги на «непонятно, как должно быть»
• Через неделю после релиза приходит правка «тут на самом деле должно быть иначе»

Каждый такой случай — не вина разработчика. Это след того, что решение принимали без вас и без контекста.

### Вопросы для саморевью перед передачей

Задайте себе вслух — и ответьте честно:

• Если я уйду в отпуск завтра, сможет ли другой человек собрать этот экран без меня?
• Что произойдёт, если данных нет вообще?
• Что произойдёт, если данных слишком много?
• Какие три вопроса задаст разработчик первым делом — и есть ли на них ответ в макете?
• Какие решения я держу в голове, но не зафиксировал?

Последний вопрос — самый болезненный. Обычно там и прячется половина проблем.

## Типичные анти-паттерны

### «Финальный макет v7 FINAL final»

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

### «Я объясню на созвоне»

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

### «Подгоню по ходу»

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

### «Это же очевидно»

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

### Пиксель-перфект как замена системности

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

## Как встроить это в макет, а не держать рядом

Документация, которая лежит отдельно от макета, не читается. Цель — чтобы вся нужная информация была там, куда разработчик и так смотрит.

### Что класть прямо во фрейм

• Подписи к состояниям: что триггерит каждое
• Аннотации к интерактиву: что происходит при клике, фокусе, наведении
• Ссылки на компоненты библиотеки рядом с кастомами
• Правила адаптива: на каком брейкпоинте что меняется
• Тексты ошибок и пустых состояний — финальные, не плейсхолдерные

### Что выносить в тикет или спеку

• Бизнес-логика и условия отображения
• Связи с другими экранами и флоу
• Аналитика: какие события трекаются и на каких действиях
• Открытые вопросы и принятые компромиссы

Разделение простое: визуальное поведение — в макете, логика и контекст — в тикете. Если смешать, ничто не будет читаться целиком.

## Короткий итог сегмента

Хендофф ломается не потому, что дизайнер плохой, а потому что стадия «доведение до разработки» не выделена в отдельную работу. Её пропускают, потому что визуально макет уже выглядит готовым. Но именно в этой пропущенной фазе — состояния, edge cases, аннотации, сверка с системой — и живёт разница между интерфейсом, который собирается за спринт, и интерфейсом, который доделывается ещё месяц после релиза.

## Продвинутые сценарии: где обычный хендофф уже не работает

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

### Сценарий: фича живёт между двумя командами

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

Что помогает:

• Явно отметить на макете, какие элементы — чужой компонент, а какие — ваш
• Согласовать поведение на стыке до передачи, не после
• Назвать ответственного за каждый кусок прямо в тикете, не в чате

### Сценарий: дизайн-система ещё не доросла

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

### Сценарий: тёмная тема, локали, плотности

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

## AI и MCP в передаче: что реально работает, а что — иллюзия

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

### Что AI реально ускоряет

• Превращение макета в первичный JSX/HTML-скелет
• Генерацию повторяющейся вёрстки списков и карточек
• Сверку отступов с токенами и поиск отклонений
• Описание состояний и пустых экранов, если разработчик ленится их перечислять

То есть рутину, где структура уже задана, а решение принято. Там, где AI не надо ничего домысливать, он экономит часы.

### Где AI стабильно подводит

• Логика поведения: что происходит после клика, какой статус идёт в стор
• Edge cases, которых нет в макете — он додумает, и додумает мимо
• Привязка к существующим компонентам: сгенерирует свой div вместо вашего Button
• Доступность: фокусы, роли, порядок навигации с клавиатуры

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

### Практика, которая снижает риск

• Передавайте в AI не голый макет, а макет вместе с описанием состояний и ссылками на компоненты
• На ревью отдельной строкой проверяйте: совпадают ли использованные компоненты с библиотечными
• Любую логику, которую модель сгенерировала «по смыслу», проговаривайте с разработчиком вслух
• Не отдавайте AI принятие решений о текстах ошибок и пустых состояний — это продукт, не верстка

## Как проверить качество хендоффа до того, как он уйдёт в работу

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

### Мини-чеклист перед передачей

• Все состояния названы и видны в одном фрейме рядом
• Пустое, загрузка, ошибка, частичные данные — есть для каждой зоны экрана
• Каждый кастомный элемент либо помечен как кастом, либо заменён на компонент
• Тексты — финальные, не lorem и не «текст-плейсхолдер»
• Адаптив описан хотя бы для двух брейкпоинтов
• Аналитика и условия отображения — в тикете
• Есть имя ответственного за открытые вопросы

Если хоть один пункт не закрыт — это не катастрофа. Но это надо отметить явно, а не оставить как «потом разберёмся».

## Как объяснять решение команде

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

Полезный формат — три уровня:

• Что мы делаем. Одно предложение про сам экран
• Почему так. Какое продуктовое или пользовательское ограничение это закрывает
• Что осознанно не делаем. Сценарии, которые рассмотрели и отложили

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

## Короткий итог сегмента

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

## Анти-паттерны хендоффа, которые встречаются чаще всего

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

### «Финальный макет», который на самом деле черновик

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

### Компонент-двойник

В библиотеке есть Button/Primary, но в макете лежит свой прямоугольник «почти как Primary, только padding другой». Разработчик либо ставит библиотечную кнопку и теряет ваши пиксели, либо плодит ещё один локальный вариант. И то и другое — долг. Если действительно нужен новый вариант — это отдельная задача в систему, а не тихая правка в продуктовом макете.

### «Логика будет в Jira»

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

### Адаптив «потом разберёмся»

Десктоп вылизан, мобайл — один экран «для понимания идеи». В проде мобайл — это 60–80% трафика. Разработчик принимает все решения по тач-таргетам, переносам, скрытию колонок сам, и это нормально только если вы заранее договорились, что так и работаете.

### Тёмная тема в последний день

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

### Локали по остаточному принципу

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

## Вопросы, которые стоит задать себе на ревью

Это не вопросы заказчику и не вопросы разработчику. Это вопросы самому себе перед тем, как нажать «передать в разработку».

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

Если на любой вопрос ответ «не знаю» или «надо посмотреть» — это место, куда вернутся вопросы от команды. Лучше закрыть сейчас.

## Расширенный чеклист: всё, что должно быть в передаче

Не для каждого экрана нужен весь список — но пройтись по нему глазами полезно.

### Содержание макета

• Все состояния собраны в одном фрейме и подписаны
• Граничные данные: пустое, одно, много, очень много, ошибка
• Длинные тексты на реальной локали, а не на той, где удобнее
• Тёмная тема проверена на тех же сценариях, что и светлая
• Адаптив минимум для двух брейкпоинтов, явно указаны точки

### Привязка к системе

• Каждый элемент — либо из библиотеки, либо помечен как кастом
• Отступы и радиусы — токены, а не магические числа
• Иконки из единого набора, а не из трёх разных
• Цвета через переменные, а не хардкод

### Контекст и логика

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

## Короткий практический итог

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

Дизайнер, который это понял, перестаёт спорить про «кто должен думать про edge cases» и начинает закрывать их сам — потому что иначе их закроет разработчик, и закроет так, как удобно ему, а не пользователю. Это менее заметная работа, чем красивый макет в дрибббл-стиле, но именно она превращает дизайн в продукт.