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

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

Полезно мыслить не отдельным экраном, а пакетом передачи. В него входят сами макеты, компоненты и их варианты, размеры и отступы, адаптивные ограничения, тексты для пустых и ошибочных состояний, список ресурсов и короткие критерии проверки. Такой пакет не превращает макет в готовый production-код автоматически, но заметно сокращает количество уточнений и повторных правок.

Что должно быть в пакете передачи

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

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

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

Состояния, размеры и адаптивные ограничения

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

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

С адаптивностью важно не смешивать макет и реализацию. Auto Layout и constraints в Figma помогают смоделировать, как блоки должны вести себя при изменении размеров фрейма, и передать это как ожидаемое правило. Но сами по себе они не делают готовый интерфейс адаптивным: разработчик еще должен реализовать эти правила в коде. Поэтому в передаче лучше писать не «адаптивность настроена», а «на ширине до 360 форма занимает всю ширину контейнера, на ширине от 768 кнопка и пояснение остаются в одной колонке».

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

Как описать поведение без двусмысленностей

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

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

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

Учебный пример: форма обратной связи

Учебный пример. Допустим, дизайнер передает форму обратной связи с тремя полями: имя, email и сообщение, плюс кнопка «Отправить». На десктопе ширина формы условно 480, на мобильном экране она растягивается на ширину контейнера с внешними отступами 16. Между полями — 12, между последним полем и кнопкой — 16. У кнопки одна высота во всех состояниях, чтобы макет не «прыгал» при смене текста.

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

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

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

Проверка перед передачей

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

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

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

С темой связан курс Figma для Full-Stack разработчика: От идеи до совершенного дизайна. По сохраненному описанию каталога в программе есть блоки про Auto Layout и constraints, а также про прототипирование и передачу в разработку. Если вы выбираете обучение под такую задачу, спросите себя: будет ли в программе самостоятельная практика именно по handoff, как преподаватель проверяет полноту спецификации и дадут ли вам обратную связь не по картинке, а по качеству передачи макета.