Как подготовить макет Figma к передаче разработчику: чек-лист с примерами

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

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

1. Зафиксируйте границы задачи

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

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

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

2. Организуйте страницы и названия

Выделите место для согласованных экранов, компонентов и рабочих исследований. Названия должны помогать поиску: «Проекты / Создание / Ошибка сохранения» понятнее, чем «Frame 284 copy». Не обязательно переименовывать каждый декоративный слой, но основные контейнеры, действия и повторяющиеся элементы должны читаться без экскурсии по файлу.

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

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

3. Приведите повторяющиеся элементы к компонентам

Поля, кнопки, уведомления и карточки лучше передавать как согласованную систему. Проверьте, не отличаются ли одинаковые кнопки случайным радиусом или внутренним отступом. У состояния должен быть смысл: primary и secondary описывают роль, loading — текущую работу, disabled — недоступность действия.

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

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

4. Покажите состояния формы

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

Учебное правило названия: от 1 до 80 символов после удаления пробелов по краям. Его нужно проверить с разработчиком: какие символы считаются, разрешены ли одинаковые названия и как обрабатываются переносы. Текст ошибки должен объяснять конкретную проблему и оставлять введённые данные доступными для исправления.

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

5. Опишите поведение между ширинами

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

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

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

6. Свяжите значения с правилами системы

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

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

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

7. Подготовьте ресурсы для реализации

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

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

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

8. Дополните прототип правилами взаимодействия

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

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

В официальном руководстве Figma по Dev Mode описаны инструменты просмотра свойств, получения ресурсов и организации передачи дизайна. Доступные функции зависят от условий аккаунта. Если команда использует отметки готовности, ставьте их после согласования; эти отметки должны соответствовать реальному состоянию задачи.

9. Превратите решения в критерии приёмки

Хороший критерий можно воспроизвести. Вместо «форма удобная» напишите: «При попытке отправить пустое название под полем появляется объяснение; остальные значения сохраняются». Вместо «мобильная версия как в макете» перечислите порядок блоков и поведение при длинном тексте.

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

10. Проведите совместную проверку

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

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