Гайд по хенд-оффу: как передавать макеты разработчикам без боли

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

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

—

## Что такое хенд-офф и почему он так важен?

**Хенд-офф** (hand-off) — это не «скинуть ссылку на Figma». Это полноценная передача дизайна команде разработки: визуальные макеты, логика взаимодействия, технические спецификации и семантика. Важно понимать: разработчик видит интерфейс не как целостную картину, а как набор переменных, отступов и обработчиков событий. Если какая-то деталь не описана, он её либо додумает, либо проигнорирует — и оба варианта ведут к расхождению с макетом.

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

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

—

## Этап 1: Подготовка макетов перед передачей

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

### 1.1. Структура и организация файлов

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

**Рекомендуемая структура:**

* **Cover Page:** Описание проекта, версия, ответственный дизайнер и дата актуальности.
* **Design System:** Все компоненты, цветовые токены, типографика и иконки — как эталон для разработчиков.
* **Mobile / Desktop:** Разделение по платформам, если проект мультиплатформенный.
* **Flows:** Конкретные пользовательские сценарии: «Регистрация», «Покупка», «Восстановление пароля».
* **States:** Сгруппированные состояния ключевых элементов (активное, ошибочное, загрузка, пустое).
* **Assets:** Экспортированные графические ресурсы в необходимых форматах.

**Чек-лист организации:**

• ☐ Все страницы имеют понятные названия — никаких Test и Untitled.
• ☐ Компоненты вынесены в отдельную библиотеку; локальные варианты синхронизированы с DS.
• ☐ Auto Layout используется на всех повторяющихся блоках — карточки, формы, списки.
• ☐ Нет скрытых, пустых или дублирующихся слоёв.
• ☐ Все иконки — векторные (SVG), растровые изображения оптимизированы под WebP или PNG.

### 1.2. Использование Auto Layout и адаптивности

Разработчик работает с CSS Flexbox и Grid — mental model очень близка к Auto Layout в Figma. Если дизайнер не использует авто-лейаут, он заставляет верстальщика вручную вычислять отступы и логику растяжения, что плодит баги.

**Что нужно проверить:**
* Кнопки, карточки и поля ввода обёрнуты в Auto Layout с понятными значениями padding и gap.
* Отступы одинаковы для однотипных элементов — это сокращает количество переменных в коде.
* Поведение при изменении ширины: «Fill container» или «Hug contents» должны соответствовать ожидаемому результату на разных разрешениях.

**Типичный случай из практики:** В edtech-проекте форма регистрации была собрана на абсолютных позициях. На мобильных устройствах поля вылезали за границы экрана. После перевода на Auto Layout с Fill container баги по адаптиву сократились на две трети.

### 1.3. Состояния (States) и интерактивность

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

Обязательный минимум:
* **Default** — базовое состояние.
* **Hover** — реакция на наведение курсора.
* **Active / Focus** — для клика и навигации с клавиатуры.
* **Disabled** — неактивный элемент.
* **Error** — валидация с текстом ошибки.
* **Success / Loading** — обратная связь после действия.

В Figma это делается через **Variants** компонента. Например, поле ввода должно включать варианты: empty, filled, error, disabled. Когда разработчик видит один компонент с понятными вариациями, ему достаточно один раз настроить поведение, а не угадывать на каждом экране. В проекте интернет-банка мы специально выделяли loading state для кнопки «Оплатить», чтобы избежать повторных кликов при медленном ответе сервера. Это убрало целый класс пользовательских жалоб.

—

## Этап 2: Описание логики и интерактивности

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

### 2.1. Прототипирование в Figma

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

**Базовый подход:**

1. Выберите интерактивный элемент.
2. Перейдите на вкладку «Prototype».
3. Протяните связь к целевому экрану.
4. Настройте анимацию — Smart Animate для плавных изменений, Slide In/Out для боковых панелей.
5. Укажите триггер: On Click, While Hover, After Delay.

В реальном проекте регистрации пользователя я связывал все экраны цепочкой и добавлял анимацию появления модалки подтверждения. Разработчик сразу видел: клик по «Зарегистрироваться» → модальное окно → успех с авторедиректом. Это сняло горы вопросов на созвоне.

### 2.2. Описание анимаций и переходов

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

**Что должно быть зафиксировано:**
* Тип анимации: появление, сдвиг, масштабирование, изменение прозрачности.
* Длительность и кривая easing (например, ease-out для естественного замедления).
* Направление: слева направо, снизу вверх.
* Триггер: клик, наведение, состояние загрузки.

Пример описания из практики:

«Модальное окно подтверждения появляется с анимацией Slide Up, 400ms, easing: ease-out. Закрытие — Slide Down, 300ms. Если действие невозможно, окно вибрирует (shake) 200ms. Индикатор загрузки карты появляется через 200ms после клика с плавным увеличением непрозрачности от 0 до 1.»

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

### 2.3. Логика ошибок и подтверждений

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

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

—

## Этап 3: Технические требования и спецификации

Здесь дизайнер перестаёт быть визуализатором и становится инженером: все значения должны быть переданы в том виде, в котором они лягут в CSS-код.

### 3.1. Цветовая палитра

Недостаточно показать цвет — его нужно дать в форматах HEX, RGB, HSL и при необходимости с альфа-каналом. Разработчик должен иметь возможность скопировать значение напрямую.

Рекомендация: если в Figma настроены Color Styles с осмысленными названиями (Primary, Text/Light, Danger), их можно связать с CSS-переменными. Это ускоряет работу и снижает вероятность путаницы.

Пример таблицы цветов для передачи:

В одном edtech-проекте мы столкнулись с тем, что разработчик использовал розовый вместо красного для ошибок, потому что в макете был только визуальный образец без точного HEX. С тех пор я всегда дублирую цвета таблицей.

### 3.2. Шрифты и типографика

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

Что передавать:
* Family: Roboto, Inter, локальная системная замена.
* Size в px.
* Weight (число: 400, 500, 700).
* Line Height в px или относительное значение.
* Letter Spacing, если оно не дефолтное.
* Цвет (HEX).

Таблица стилей:

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

### 3.3. Отступы и сетка

Отступы — это не «примерно 15px», а жёсткая система. Я всегда рекомендую 8‑пиксельную сетку как стандарт, который хорошо ложится на большинство экранов и упрощает верстку.

Типовые значения:

• Малый отступ: 8px
• Средний: 16px
• Большой: 24px
• Очень большой: 32px

Если макет использует отступы 15px или 23px, это сигнал, что дизайн не приведен к системе. Разработчику придётся либо городить исключения, либо округлять, что искажает задумку.

### 3.4. Иконки и изображения

Иконки — SVG, это аксиома. Растровые иконки мы используем только в исключительных случаях (например, сложные эмбеддинговые изображения). Для фото и иллюстраций указываем формат: WebP для современного веба с фолбэком на JPEG/PNG, если нужна поддержка старых браузеров.

Размеры иконок должны быть кратки: 16px, 24px, 32px, 48px. Все иконки собраны в компонентной библиотеке — разработчик может выгрузить их пакетом и использовать как компоненты или спрайт.

В реальной работе я сталкивался с тем, что неоптимизированные PNG-иконки размером 200×200px замедляли загрузку страницы в разы. Сейчас правило простое: если элемент векторный, он должен быть SVG.

—

## Этап 4: Коммуникация и процесс передачи

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

### 4.1. Встреча по передаче (Hand-off Meeting)

Кинуть ссылку в чат недостаточно. Даже идеально подготовленный файл может вызвать вопросы, которые проще решить голосом. Я провожу короткую встречу в Figma Live или Zoom, где последовательно прохожу по флоу, фиксирую ключевые решения и отвечаю на вопросы.

Примерный план встречи:

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

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

### 4.2. Использование комментариев в Figma

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

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

### 4.3. Документация и чек-листы

Документ с кратким обзором проекта и сводкой всех спецификаций — это must-have. Он служит единым источником истины для всей команды. Обычно я включаю туда ссылки на цветовые стили, типографику, сетку, описание компонентов и сценарии edge cases.

Чек-лист готовности к передаче:

—

## Типовые ошибки и как их избежать

Ошибки в хенд-оффе стоят дорого. Вот те, с которыми я сталкивался чаще всего, и способы их предотвратить.

### Ошибка 1: Использование фиксированных размеров

Фиксированная ширина кнопки 200px на десктопе ломается на планшете. Как избежать: всегда настраивать Auto Layout с Fill container или Hug contents, проверять поведение на трёх контрольных точках: 320px, 768px, 1440px. В одном проекте мы специально ввели правило: каждый компонент до передачи должен пройти стресс-тест на изменение ширины контейнера.

### Ошибка 2: Отсутствие состояний

Если в макете только Default, разработчик не воспроизведёт ни hover, ни disabled. Решение: сделать компонент с вариантами через Variants. Обязательно включить loading state для действий, которые требуют серверного ответа.

### Ошибка 3: Неясная логика взаимодействия

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

### Ошибка 4: Произвольные отступы

Отступ 15px не существует в стандартной сетке. Решение: придерживаться 8px baseline, в исключительных случаях 4px. Разработчик сможет оперировать переменными, а не магическими числами.

### Ошибка 5: Отсутствие документации

Без единого документа команда через месяц забудет, почему был выбран именно этот цвет ошибки. Чек-лист: файл документации (Figma/Notion) с цветами, типографикой, описанием нестандартных решений и ссылками на компоненты.

—

## Чек-лист: готовность макета к хенд-оффу

Перед тем как нажать «Share», пройдите по этому списку. Если все пункты отмечены — можно смело отправлять.

### Визуальная часть

• ☐ Все страницы и фреймы осмысленно названы.
• ☐ Компоненты вынесены в библиотеку.
• ☐ Auto Layout применён к карточкам, формам, спискам.
• ☐ Нет скрытых или неиспользуемых слоёв.
• ☐ Иконки в SVG, изображения оптимизированы.
• ☐ Варианты состояний включают Default, Hover, Active/ Focus, Disabled, Error, Success / Loading.

### Логика и интерактивность

• ☐ Прототип покрывает основные сценарии.
• ☐ Анимации задокументированы: тип, длительность, easing, направление.
• ☐ Логика ошибок и подтверждений описана (текст, положение, тайминг).
• ☐ Все переходы между экранами показаны и промаркированы.

### Технические требования

• ☐ Цвета вынесены в таблицу с HEX, RGB, HSL, Alpha.
• ☐ Типографика оформлена в виде стилей с полным перечнем параметров.
• ☐ Отступы приведены к 8-пиксельной сетке.
• ☐ Иконки и изображения в нужных форматах и разрешениях.

### Коммуникация

• ☐ Проведена встреча по передаче (запись доступна).
• ☐ Документация передана вместе с файлом.
• ☐ Разработчик подтвердил ознакомление.
• ☐ Ключевые вопросы вынесены в комментарии Figma и обработаны.

Если всё выполнено, ваш макет готов к хенд-оффу без стресса и догадок.

—

## FAQ: Часто задаваемые вопросы о хенд-оффе

### 1. Что делать, если разработчик не понимает макет?
Не играйте в испорченный телефон. Откройте Figma Live и проведите короткую демонстрацию. Если барьер системный — запишите пятиминутный скринкаст с озвучкой логики. В одном финтех-проекте мы создали мини-библиотеку таких видео, и число однотипных вопросов упало на 80%.

### 2. Как описать анимации, если в Figma нет нужного типа?
Используйте максимально близкий аналог (Smart Animate, Slide) как отправную точку. Остальное опишите текстом: свойства «transform», длительность, кривую. Разработчик воспроизведёт это вручную — главное, чтобы он понимал, что должно получиться.

### 3. Что делать, если макет не соответствует техническим ограничениям?
Не продавливайте красоту в ущерб реализуемости. Обсудите с разработчиком: возможно, вместо сложной анимации достаточно микро-взаимодействия. Учитывайте реальные API-лимиты, производительность на слабых устройствах и доступность.

### 4. Как использовать Auto Layout для адаптивности?
Стройте компоненты с шириной Fill container или Hug contents. Проверьте, как они перестраиваются при изменении ширины родителя — в Figma это делается обычным перетаскиванием краёв фрейма в режиме prototype.

### 5. Что делать, если разработчик не использует Figma?
Экспортируйте макеты в PDF или PNG с аннотациями, приложите спецификацию отдельно. Но всё же уговорите команду хотя бы на бесплатный аккаунт — без прямого доступа в макет процесс кратно дольше.

### 6. Как проверить, что макет готов к хенд-оффу?
Пройдите по чек-листу из предыдущего раздела. Если все пункты с галками — макет готов.

### 7. Что делать, если макет не соответствует стандартам дизайна?
Приведите его к стандартам до передачи. Если время поджимает, зафиксируйте расхождения в документации и создайте задачу на рефакторинг в ближайшем спринте.

### 8. Как использовать комментарии в Figma для уточнений?
Выделяйте конкретный элемент и пишите вопрос в контексте. Назначайте ответственного разработчика. Комментарий должен быть точным, а не «что-то тут не так». После решения закрывайте треды.

### 9. Что делать, если макет не соответствует требованиям пользователя?
Вернитесь на этап UX-исследования. Хенд-офф — не место для выяснения потребностей; к этому моменту сценарии должны быть валидированы.

### 10. Как использовать документацию для передачи макета?
Документация — это не книга, а шпаргалка. Соберите в одном месте все токены, компоненты и edge cases. Держите её актуальной и привязывайте к версии макета.

—

## Вывод: Хенд-офф как инструмент качества

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

Ключевые правила, которые стоит держать в голове:

• Auto Layout и компоненты — ваша защита от адаптивного хаоса.
• Варианты состояний обязательны для каждого интерактивного элемента.
• Прототип заменяет десяток текстовых пояснений.
• Цвета и типографика передаются в стилях и таблицах, а не на глаз.
• 8‑пиксельная сетка — стандарт, вокруг которого всё строится.
• Встреча и документация закрывают коммуникационные разрывы.

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