Короткий ответ
Передача дизайна не оставляет места догадкам, когда кроме экранов в ней зафиксированы семь вещей: какие фреймы окончательны и в какой версии, все состояния каждого компонента, включая ошибки и пустые экраны, дизайн-токены, стоящие за значениями, поведение макета между размерами, правила для реального контента, ассеты с лицензиями и критерии приёмки каждого экрана. Вопросы идут по одному каналу, а каждый ответ записывается обратно в файл.
Каждый пробел в макете становится решением не того человека
Дизайн-файл отвечает на вопросы, о которых подумал его автор. Остальные задаёт производство: как выглядит эта кнопка, пока идёт оплата, что будет с карточкой, если в имени сорок символов, какой это серый. Если файл молчит, решает разработчик — один и в условиях дедлайна, — и это решение уходит в продукт.
Дело не в небрежности ни одной из сторон. Макет показывает один момент интерфейса с идеальным контентом, а интерфейс — это сотни моментов с настоящим. Разрыв между ними и есть передача, и заполняет его либо записанное правило, либо догадка. Догадку дёшево сделать и дорого потом найти.
Передача дизайна в разработку, не оставляющая места догадкам, содержит кроме экранов семь вещей: статус каждого фрейма, все состояния и граничные случаи, токены, адаптивные правила, правила контента, ассеты с лицензиями и критерии приёмки. Восьмая скрепляет остальные: одно место, где задают вопросы и получают ответы.
Отметьте, что закончено и какая это версия
Первое, о чём приходится гадать разработчику, — окончателен ли фрейм. В файлах рядом с утверждённой работой лежат поиски, отклонённые варианты и недоделанные идеи, и выглядят они одинаково настоящими. Запишите объём словами: список экранов и компонентов этого релиза и видимый статус на каждом.
Инструменты дизайна теперь поддерживают это напрямую. Документация Figma описывает Dev Mode как рабочее пространство для инспектирования макетов, сравнения изменений и управления передачей в разработку; фреймы, компоненты и секции можно пометить статусом «Ready for dev», а текущую версию фрейма — сравнить с предыдущими. Каким бы инструментом вы ни пользовались, принцип тот же.
Статус — это обещание, поэтому всё, что меняется после него, считается изменением. Если утверждённый фрейм правят, рядом оставляют короткую датированную заметку о том, что изменилось и почему, и сообщают тем, кто его реализует. Молчаливая правка «готового» экрана — путь, которым в продукт попадают две версии одного компонента.
Нарисуйте каждое состояние, затем неудобные случаи
Компонент — это не одна картинка. Спецификации Material Design группируют токены компонента сначала по состоянию — «enabled, disabled, hover, etc», то есть включён, отключён, наведение и так далее, — и только потом по элементу; для передачи это хорошая модель. У каждого интерактивного компонента покажите обычное состояние, наведение, фокус с клавиатуры, нажатие и отключённое, а у всего, что ждёт данных, — ещё загрузку, успех и ошибку.
Затем спроектируйте случаи, которые не попадают в презентации. Пустой список до появления первого элемента. Поиск без результатов. Имя втрое длиннее образца, фото, которое не загрузилось, таблица с одной строкой и с тысячей. Пользователь без прав доступа и пользователь на медленном соединении.
Удержать это помогает таблица состояний: компоненты по вертикали, состояния по горизонтали, в каждой ячейке ссылка или пометка. Пустая ячейка — вопрос, который зададут посреди спринта. «Как в обычном состоянии» — законный ответ; просто записать его должен дизайнер, а не предположить разработчик.
Токены превращают скопированные значения в названные решения
Material Design определяет дизайн-токены как небольшие повторно используемые дизайн-решения, из которых складывается визуальный стиль системы и которые заменяют статичные значения понятными именами. В той же документации приведён и довод в пользу передачи: когда макет дизайнера и код инженера ссылаются на один токен, оба уверены, что используется один цвет, даже если его шестнадцатеричное значение позже обновят.
Теперь для токенов есть общий формат файла. Сообщество Design Tokens Community Group в октябре 2025 года опубликовало Design Tokens Format Module 2025.10 как стабильный отчёт; в нём отмечено, что документ не является стандартом W3C. Токены хранятся в JSON, у каждого есть значение и тип, при желании — описание назначения, а токен может быть псевдонимом, который указывает на другой токен.
Практический минимум для передачи — таблица или файл токенов для цвета, типографики, отступов, скруглений, теней и анимации, причём имена говорят, для чего значение нужно, а не как оно выглядит. Полезный образец — три класса Material: референсные токены для доступных исходных значений, системные для ролей, компонентные для частей компонента. Всё, что в файле не использует токен, помечают как намеренное исключение.
Адаптивность — это набор правил, а не три скриншота
Три макета — для телефона, планшета и десктопа — описывают три ширины из тысяч. Производству нужно поведение между ними: какие элементы растягиваются, какие сохраняют размер, какие переносятся на новую строку, какие встают друг под друга, какие исчезают и в каком порядке. Запишите это правилами, привязанными к раскладке, с минимальной и максимальной шириной там, где они есть.
Укажите, где раскладка меняется и почему. Контрольная точка полезна, когда привязана к содержимому, например к ширине, при которой навигация перестаёт помещаться в одну строку, и произвольна, когда списана с перечня устройств. Скажите и о том, что остаётся постоянным: ширина текстовой колонки, размер областей нажатия, шкала отступов.
Ширина — лишь одно из условий. Документация Material Design о токенах перечисляет другие под именем контекстов: форм-факторы устройств, тёмная тема, плотные раскладки и письменности с направлением справа налево. В передаче стоит сказать, какие из них продукт поддерживает в этом релизе, и показать хотя бы один ключевой экран в каждом, чтобы остальное выводилось из токенов и правил.
Правила контента: настоящий текст, пределы и то, что за ними
Текст-заполнитель скрывает большинство проблем раскладки. Передавайте настоящие тексты для каждого экрана, включая подписи кнопок, сообщения об ошибках, пустые состояния и письма-подтверждения, написанные или утверждённые тем, кто отвечает за слова. Разработчик, которому пришлось придумать сообщение об ошибке, его напишет, и оно дойдёт до пользователей.
Для каждого текстового элемента, который заполняется данными, дайте правило: ожидаемая длина, максимальная и то, что происходит за ней, — переносится ли текст, обрезается ли с возможностью увидеть остальное или уменьшается. То же для изображений: пропорции, способ кадрирования и то, что показывается, когда изображения нет.
Добавьте форматы, которые зависят от языка и региона: даты, время, числа, валюта, множественное число. Если продукт будут переводить, проверьте раскладку на самом длинном из планируемых языков и на языке с письмом справа налево, если он нужен. И дайте каждому значимому изображению текстовую альтернативу уже при передаче: это тоже контент, который кто-то должен написать.
Ассеты и лицензии передаются вместе с файлом
Гадать, как экспортировать ассеты, разработчик тоже не должен. Перечислите, что нужно и в каком формате: векторные файлы для иконок и логотипов, растровые изображения в тех размерах и плотностях, которые использует продукт, видео и анимации с их настройками. Dev Mode в Figma, например, позволяет скачивать ассеты и экспортировать слои в PNG, JPG, SVG и PDF, но кто-то всё равно должен сказать, что именно.
Имена важнее, чем кажется. Единый шаблон имён, совпадающий с именами в коде, избавляет всех от таблицы соответствий, а одна согласованная папка или библиотека — от вопроса, какой логотип актуален. Вместе с передачей храните исходники в полном разрешении, а не только сжатые экспортные файлы.
Затем лицензии. Для каждого шрифта укажите, какая лицензия покрывает его использование на сайте или в приложении и на кого она оформлена. То же сделайте для стоковых фотографий, иллюстраций, наборов иконок и музыки. Макет можно собрать на пробном шрифте или на превью с водяным знаком; выпущенному продукту нужна настоящая лицензия, и разработчик не узнает, где что, если этого не сказано в передаче.
Критерии приёмки и один канал для вопросов
Руководство Service Manual правительства Великобритании описывает критерии приёмки как список результатов, который используют как чек-лист, чтобы убедиться, что сервис сделал своё дело и отвечает потребности пользователя; часто это список, начинающийся словами «it’s done when…» — «готово, когда…». Тот же приём работает для экрана: он готов, когда реализованы все состояния из таблицы, совпадают токены, правила раскладки выполняются на любой ширине и помещается настоящий контент.
Запишите критерии до начала разработки и проверяйте сборку по ним, на реальных устройствах и вместе с дизайнером. Так ревью дизайна превращается из вопроса вкуса в сверку со списком, а у разработчика появляется что проверить самому, прежде чем звать на ревью.
Наконец, выберите один канал для вопросов и назовите его в передаче. Вопрос, заданный в чате, решённый на звонке и оставшийся в памяти двух человек, потерян для всех остальных. Держите вопросы рядом с дизайном — в комментариях или аннотациях к фрейму, — назовите того, кто отвечает, и срок ответа, а каждый ответ записывайте обратно в файл как правило. Тогда следующий проект начнётся с меньшим числом пробелов.
Практический чеклист
- Отметьте статусом каждый фрейм, входящий в объём работ, и записывайте каждое изменение, сделанное после отметки о готовности.
- Заполните таблицу состояний для каждого компонента, включая загрузку, ошибку, пустое состояние и отсутствие прав.
- Передайте токены файлом или таблицей с именами по назначению и пометьте каждое значение, которое токен не использует.
- Запишите словами правила адаптивности, контента и изображений и проверьте раскладку на самом длинном настоящем тексте.
- Перечислите ассеты с форматами и лицензиями, напишите критерии приёмки для каждого экрана и назовите один канал для вопросов.
Вопросы и ответы
Что должно входить в передачу дизайна в разработку?
Кроме экранов: статус, показывающий, какие фреймы окончательны, все состояния каждого компонента, граничные случаи, дизайн-токены, правила адаптивного поведения, настоящий контент с его пределами, ассеты с лицензиями и критерии приёмки каждого экрана. Добавьте один названный канал для вопросов. Если разработчик может собрать экран, не спрашивая, что происходит, когда данных нет или они слишком длинные, передача полная.
Что такое дизайн-токены и нужны ли они небольшому проекту?
Дизайн-токены — это названные дизайн-решения, например цвет, шаг отступа или размер шрифта, которые хранятся в одном месте и используются по ссылке. В документации Material Design сказано, что они полезнее всего, когда продукт будут обновлять, когда он работает на нескольких платформах или опирается на дизайн-систему, и менее полезны для существующего приложения с жёстко заданными значениями, которое вряд ли изменится. Небольшой проект может начать с короткой таблицы названных цветов, размеров и отступов.
Является ли формат дизайн-токенов официальным стандартом W3C?
Нет. Design Tokens Format Module 2025.10 опубликовало сообщество Design Tokens Community Group, работающее по процедуре групп сообщества W3C, и в самом документе сказано, что он не является стандартом W3C и не находится на пути стандартизации W3C. Группа называет спецификацию стабильной и предназначенной для реализации. Прежде чем строить на ней инструменты, проверьте актуальную версию на сайте группы.
Какие состояния нужны каждому компоненту интерфейса?
Это зависит от компонента, но привычный набор для интерактивного элемента — обычное состояние, наведение, фокус с клавиатуры, нажатие и отключённое. Элементам, которые зависят от данных, нужны ещё загрузка, успех, ошибка и пустое состояние. Спецификации Material Design по той же причине упорядочивают значения компонентов по состояниям. Перечислите состояния в таблице и напишите «как в обычном», где это и есть ответ, чтобы ничего не оставалось на догадку.
Как написать критерии приёмки для дизайна?
Составьте для каждого экрана короткий список наблюдаемых результатов в той форме, которую предлагает Service Manual правительства Великобритании: «готово, когда…». Например: готово, когда реализованы все перечисленные состояния, когда раскладка держится на любой ширине между названными минимумом и максимумом, когда помещается настоящий контент максимальной длины и когда токены в коде совпадают с токенами в файле. Согласуйте список до разработки и проверяйте сборку по нему.