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

28 августа 2026 · 10 минут · Tomsa Daria

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

Что на самом деле спрашивает разработчик

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

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

• Что происходит при нажатии? Переход, всплывающее окно, изменение на месте. И куда возвращает кнопка «назад».
• Откуда берутся данные и что если их нет? Пустой каталог, товар без фотографии, отсутствующая старая цена.
• Что с длинными и короткими данными? Название в 120 знаков, цена в шесть цифр, имя пользователя из одной буквы.
• Правила проверки формы. Когда показывается ошибка — при вводе, при потере фокуса или при отправке. И точные тексты ошибок, а не слово «ошибка».
• Что происходит во время ожидания? Кнопка блокируется, показывается скелетон, экран не прыгает.
• Что видно при работе с клавиатуры? Порядок обхода табом, где рамка фокуса, что закрывает Escape.
• Как ведут себя блоки при сужении? Не «сделай адаптив», а поведение каждого блока.
• Чего в задаче нет. Явный список: избранное не делаем, входа через соцсети нет. Незакрытая граница задачи — источник конфликта на приёмке.

Порядок в файле: страницы, именование, что удалить перед сдачей

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

Приведите список страниц к такому виду: → Готово к разработке, 01 Экраны — десктоп, 02 Экраны — мобильные, 03 Компоненты, 04 Стили и переменные, 05 Архив. Стрелка в имени первой страницы поднимает её наверх и сразу говорит, куда идти. На страницу «Готово к разработке» кладут не копии, а те самые актуальные экраны: дубли расходятся через неделю и становятся источником ошибок.

Внутри страницы группируйте экраны в Sections (клавиша Shift + S) по сценариям: «Каталог», «Товар», «Корзина», «Служебные состояния». У секции есть переключатель Ready for dev — включите его на готовых разделах, и они отметятся в режиме разработчика.

Что удалить и почистить перед сдачей: скрытые глазом слои — они остаются в файле и попадают в экспорт; отвязанные инстансы — слой с именем компонента, но без ромба; дубли стилей вида Body / M и Body/M 2, которые появляются при копировании из других файлов. Имена приведите к одной системе: экраны — по сценарию и состоянию («Каталог», «Каталог / Пусто», «Каталог / 375»), компоненты — по типу («Кнопка / Основная»), слои внутри компонента — по роли («Подпись», «Значок»), а не «Text 4».

Черновики не удаляйте — переносите на страницу «Архив». Через месяц заказчик спросит, почему отказались от варианта, и вариант должен найтись. И заведите именованную версию: File → Show version history, точка с именем вида «Передача в разработку». Это единственный способ вернуться к состоянию, которое согласовали.

Опасная привычка, которую стоит бросить сразу: несколько копий одного экрана с именами «Каталог финал», «Каталог финал 2», «Каталог финал итог». Разработчик возьмёт не тот, и виноват будет не он. Правило простое: одна задача — один экран.

В курсе «Интерфейсы в Figma» передаче в разработку отведён целый финальный модуль, и в материалах лежит шаблон передачи: структура файла и чек-лист, по которым макет принимают без сотни уточняющих вопросов.

Токены и стили вместо «просто цветов»: почему это экономит правки

В режиме разработчика при выделении слоя панель справа показывает размеры, отступы, цвета и типографику. Разница между хорошим и плохим макетом видна именно здесь: имя action/primary в панели полезно, а голый #2F5D3A заставляет разработчика заводить очередную безымянную константу. Через месяц в коде окажется восемь оттенков зелёного, и никто не сможет сказать, какие из них — один и тот же цвет.

Минимум, который стоит собрать даже в маленьком проекте: текстовые стили (заголовки, тело, подписи), цветовые переменные с ролями, числовые переменные отступов. Роль важнее оттенка: text/secondary переживёт смену палитры, а gray-500 в тёмной теме перестанет быть серым и начнёт врать.

Хорошее имя строится по грамматике «категория — роль — состояние»: bg/surface, text/primary, border/default, action/primary-hover, status/error. Проверка одна: прочитайте имя и попробуйте изменить значение. Если при этом имя перестаёт быть правдой — оно названо по внешнему виду, а не по роли.

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

Отступы тоже стоит держать переменными, особенно если у проекта есть мобильная версия: числовые переменные вроде space/section и space/page с режимами Desktop и Mobile переключают плотность всего макета одним действием, а не правкой каждого контейнера.

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

Состояния: наведение, фокус, нажатие, ошибка, блокировка, загрузка, пусто

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

Обязательный набор выглядит так. Default — покой. Hover — курсор над элементом; только для мыши, на телефоне его нет. Pressed — момент нажатия. Focus — элемент выбран с клавиатуры: рамка толщиной 2 и контраст не ниже 3:1, без этого формой невозможно пользоваться без мыши. Disabled — действие недоступно, и рядом нужен текст с причиной. Loading — для кнопки подмена подписи индикатором с сохранением ширины, для списка скелетон вместо спиннера по центру. Error — текст ошибки рядом с причиной, а не общий баннер сверху. Empty — пустая корзина, пустой результат поиска, каталог без товаров по фильтру.

Не каждому элементу нужны все восемь. Кнопке — default, hover, pressed, focus, disabled, loading. Полю — default, focus, error, disabled. Экрану — обычное состояние, загрузка, пустое, ошибка загрузки. Список кажется длинным ровно до момента, когда вы собрали состояния вариантами компонента: тогда это шесть ячеек в наборе, а не шесть отдельных экранов.

Показывать состояния лучше не отдельными картинками, а прямо в наборе вариантов: тогда разработчик видит, что это один компонент с переключателем, а не шесть разных элементов. Внутри набора состояния можно связать интерактивно — переход While hovering из Default в Hover и While pressing в Pressed, — и они заработают во всех инстансах на экранах. Заодно это проверка вас самих: если переход некуда вести, значит, состояние не нарисовано.

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

Адаптив: контрольные точки и что происходит с каждым блоком между ними

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

Контрольные точки задаёт содержимое, а не список популярных устройств: точка нужна там, где четыре карточки в ряду перестают помещаться. Рабочий набор для магазина — 1440, 1024, 768 и 375; для каждой запишите число колонок, поля и промежуток: например, на 1440 сетка 12 колонок, поля 120, промежуток 24, четыре карточки в ряду; на 768 — 8 колонок, поля 32, промежуток 16, две карточки.

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

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

Отдельно для мобильной версии зафиксируйте правила для пальца: минимальная область нажатия 44 на 44 пикселя (иконка может быть 24, но фрейм вокруг неё обязан быть 44), расстояние между соседними целями не меньше 8, текст не мельче 14. Эти числа разработчик проверит, а вы сэкономите себе круг правок.

Иконки, шрифты, картинки: форматы и как отдавать

Иконки — в SVG. Перед экспортом объедините контуры (Cmd/Ctrl + E) и переведите обводки в заливки, иначе размер иконки в вёрстке будет плавать. Настройте экспорт прямо в файле: раздел Export в панели Design, формат SVG.

Растровые картинки — в PNG или WebP, в двух плотностях. Плюс в разделе Export добавляет второй пресет: 1x и 2x с суффиксом @2x.

Имена файлов — латиницей, без пробелов: icon-cart.svg, hero-plants@2x.png. Кириллица в именах ломает сборку на части серверов.

Логотип — отдельно и в двух вариантах: цветной и одноцветный для тёмного фона.

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

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

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

Что нельзя оставить «на словах»: анимации, тексты ошибок, крайние случаи

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

Тексты. Все сообщения об ошибках, подсказки, подписи пустых состояний — дословно. «Показать ошибку» не является текстом ошибки. Сюда же — правила склонения и форматы: «2 товара» и «5 товаров», цена «124 900 ₽» или «€1 249», дата в коротком или длинном виде.

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

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

Неочевидное поведение — аннотациями. Включите режим разработчика (Shift + D), возьмите инструмент Annotate и подпишите закреплённую кнопку, ленту фильтров с прокруткой, поле поиска. Аннотация привязывается к слою и переезжает вместе с ним, а к ней можно приколоть конкретные свойства, значения которых обновятся сами при правке макета.

И самая дорогая ошибка передачи: отдать макет, в котором отступы задавались координатами. В режиме разработчика такой блок показывает расстояния, посчитанные по факту — 23, 25, 24, — и разработчик повторит эти три числа в коде. Автолейаут отдаёт padding и gap явными значениями; если блоки в файле разъезжаются, сначала стоит починить это, и мы разобрали как — в статье автолейаут в Figma разъезжается.

Живая передача: 20 минут созвона вместо трёх дней переписки

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

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

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

И короткий чек-лист перед тем, как отправлять ссылку: актуальные экраны на одной странице и отмечены Ready for dev; в файле нет слоёв с именами по умолчанию, скрытых слоёв и отвязанных инстансов; цвета и типографика показываются с именами переменных; у всех иконок настроен экспорт; для каждого экрана написаны ответы на восемь вопросов из первого раздела; есть таблица поведения блоков по контрольным точкам; тексты ошибок написаны дословно; создана именованная версия.