Хорошо подготовленный макет — это не файл, в котором идеально названы все слои. Это макет, по которому разработчику не приходится угадывать, какой экран финальный, как ведут себя элементы и что должно происходить между десктопом и мобильной версией.
Чем меньше таких догадок возникает на старте, тем точнее готовый сайт соответствует дизайну, быстрее идёт разработка и реже появляются правки в конце проекта.
Разберём, что действительно стоит проверить перед передачей макета в вёрстку, а на что можно не тратить лишнее время.
Что должен понять разработчик из макета
Макет должен отвечать на три основных вопроса:
- Какие страницы и состояния утверждены?
- Как интерфейс ведёт себя на разных экранах?
- Что происходит при взаимодействии с элементами?
Разработчику нужна ссылка на исходный файл Figma, а не PDF, набор изображений или скриншоты экранов. В исходном файле можно посмотреть размеры, отступы, стили, компоненты и подготовленную к экспорту графику.
Если используется Dev Mode, готовые фреймы можно отметить статусом Ready for dev. Это помогает отделить утверждённые экраны от черновиков и старых вариантов. Но наличие Dev Mode не обязательно: главное, чтобы внутри файла было понятно, что именно нужно реализовать.
Хорошая передача макета не описывает каждый пиксель. Она убирает места, в которых разработчику пришлось бы принимать дизайнерское решение самостоятельно.
Отделите готовые экраны от черновиков
В рабочих файлах часто остаются старые версии страниц, варианты первого экрана, временные компоненты и эксперименты. Дизайнер помнит, какой вариант утверждён, но для нового участника проекта все фреймы выглядят одинаково значимыми.
Перед передачей макета полезно создать отдельную страницу, например:
Ready for development;Final;В разработку.
На неё достаточно перенести или продублировать только актуальные экраны.
Страницы и основные фреймы лучше назвать по их назначению:
- Главная;
- Услуги;
- Карточка проекта;
- Материалы;
- Статья;
- Контакты;
- 404
Необязательно переименовывать каждый декоративный слой. Названия вроде Rectangle 153 не мешают разработке, если структура самого экрана понятна. В первую очередь осмысленные названия нужны компонентам, секциям, изображениям и элементам, которые должны повторяться на разных страницах.
Также стоит убрать скрытые элементы, которые не относятся к финальной версии, либо добавить комментарий, объясняющий их назначение.
Передайте систему, а не только набор экранов
Сайт состоит не из девяти изолированных страниц. В нём повторяются контейнеры, отступы, типографика, кнопки, карточки, поля и другие элементы.
Если эта система видна в макете, её можно так же системно перенести в код.
Типографика
Для каждого текстового стиля должны быть понятны:
- семейство шрифта;
- начертание;
- размер;
- межстрочный интервал;
- межбуквенный интервал;
- регистр.
Важно проверить, что необходимые файлы шрифтов действительно существуют и их лицензия разрешает использование на сайте. Если в макете используется начертание Medium, а в файлах есть только Regular и Bold, браузер не сможет точно воспроизвести дизайн.
Не стоит переводить обычные заголовки и тексты в кривые. Текст на сайте должен оставаться текстом: так он адаптируется, индексируется и доступен для пользователей.
Цвета и переменные
Основные цвета желательно вынести в стили или переменные:
- фон;
- основной текст;
- вторичный текст;
- акцент;
- границы;
- состояния элементов.
Переменные Figma помогают хранить повторяющиеся значения и использовать отдельные режимы для разных тем или размеров экрана. Но создавать полноценную дизайн-систему ради небольшого лендинга необязательно. Даже простого набора понятных цветовых стилей будет достаточно.
Сетка и контейнер
Разработчику важно понимать:
- максимальную ширину контента;
- количество колонок;
- внешние поля;
- расстояния между колонками;
- какие элементы выходят за пределы контейнера.
Если разные страницы используют разные контейнеры, это должно быть осознанным решением, а не случайным расхождением.
Auto Layout
Auto Layout полезен не потому, что его можно автоматически превратить в CSS. Он показывает логику элемента: внутренние отступы, расстояние между дочерними элементами и реакцию блока на изменение содержимого.
Figma позволяет создавать с помощью Auto Layout кнопки, списки, карточки и целые адаптивные композиции, которые реагируют на изменение текста и размеров контейнера.
При этом не нужно искусственно помещать в Auto Layout абсолютно каждый объект. Для разработчика важнее понятная логика блока, чем формально идеальная структура файла.
Покажите состояния и поведение элементов
Статичный фрейм показывает только один момент интерфейса. На готовом сайте у элементов появляются состояния, которых может не быть на основном экране.
Для кнопок и ссылок желательно показать:
- обычное состояние;
- наведение;
- нажатие;
- фокус с клавиатуры;
- неактивное состояние, если оно предусмотрено.
Для форм могут понадобиться:
- пустое поле;
- заполненное поле;
- ошибка;
- успешная отправка;
- состояние загрузки.
Для меню — открытая мобильная версия. Для выпадающего списка — открытое состояние. Для слайдера — логика переключения и поведение крайних слайдов.
Необязательно рисовать отдельный полноценный экран для каждого состояния. Их можно собрать рядом с компонентом или описать коротким комментарием.
Проверьте макет на реальном контенте
Карточка с двумя строками текста может отлично выглядеть в макете и развалиться после добавления настоящего контента.
Перед передачей полезно проверить:
- длинный заголовок;
- короткий заголовок;
- карточки с разным количеством текста;
- изображения разных пропорций;
- пустые значения;
- большое количество пунктов;
- длинный email или номер телефона.
Разработчик всё равно должен предусмотреть такие ситуации, но макет подсказывает, какое поведение будет соответствовать замыслу дизайнера.
Продумайте адаптивную версию
Для большинства проектов достаточно показать ключевые страницы на десктопе и мобильном устройстве. Планшетные и промежуточные состояния разработчик может собрать самостоятельно, если понятна общая логика композиции.
В мобильной версии важно показать не только уменьшенные размеры, но и структурные изменения:
- как перестраиваются колонки;
- в каком порядке идут блоки;
- что происходит с навигацией;
- какие элементы скрываются;
- превращается ли сетка карточек в слайдер;
- остаются ли декоративные элементы;
- как ведут себя таблицы и длинные строки;
- какие секции занимают всю ширину экрана.
Точная ширина фрейма не является единственной точкой переключения. В готовом сайте брейкпоинты выбираются там, где композиция перестаёт нормально работать.
Если мобильной версии в Figma нет, сайт всё равно можно сделать адаптивным. Но в таком случае часть дизайнерских решений принимает разработчик. Это нужно заранее учитывать в сроках, стоимости и процессе согласования.
Опишите анимации и интерактив
Прототип показывает общее направление движения, но часто не отвечает на технические вопросы.
Для каждой заметной анимации желательно определить:
- что запускает движение;
- какие элементы участвуют;
- в какой последовательности они появляются;
- зависит ли анимация от прокрутки;
- фиксируется ли секция на экране;
- что должно происходить на мобильных устройствах;
- можно ли упростить эффект на слабых устройствах.
Например, формулировка «карточки красиво появляются» слишком неопределённая. Гораздо понятнее: «карточки поднимаются снизу по очереди, когда секция входит в область просмотра».
Сложную сцену можно показать в прототипе, записать коротким видео или приложить ссылку на референс. Разработчик уже подберёт подходящий способ реализации — CSS, GSAP, ScrollTrigger или другую технологию.
Подготовьте изображения, иконки и шрифты
Логотипы и простые иконки лучше подготовить в SVG. Фотографии и сложные растровые изображения должны иметь достаточное разрешение для крупных экранов.
Перед передачей проверьте:
- не встроен ли логотип как маленькое растровое изображение;
- можно ли экспортировать необходимые слои;
- нет ли потерянных исходников;
- доступны ли файлы используемых шрифтов;
- не собраны ли важные изображения из нескольких случайных слоёв;
- понятно ли, какие изображения меняются через WordPress.
Figma позволяет экспортировать слои, фреймы и компоненты в нескольких форматах, включая PNG и SVG. Владелец файла при этом не должен запрещать копирование и экспорт материалов.
Финальную оптимизацию изображений обычно выполняет разработчик: выбирает подходящий формат, размеры и степень сжатия для сайта.
Чек-лист перед передачей макета
Перед отправкой ссылки разработчику проверьте:
- Все утверждённые страницы находятся в отдельной понятной области файла.
- Старые и неактуальные варианты отделены от финальных.
- Основные страницы и компоненты имеют понятные названия.
- Указаны используемые шрифты и начертания.
- Основные цвета и текстовые стили собраны в систему.
- Понятны ширина контейнера и логика сетки.
- Показаны мобильные версии ключевых экранов.
- Для интерактивных элементов предусмотрены необходимые состояния.
- Сложные анимации показаны в прототипе, видео или референсе.
- Иконки, логотипы и изображения доступны для экспорта.
- У разработчика есть доступ к исходному файлу, а не только к презентации.
- Все спорные или нестандартные решения снабжены комментариями.
Не нужно откладывать передачу макета до момента, когда файл станет идеальным. Лучше заранее показать его разработчику и вместе определить, каких данных не хватает для точной оценки.
Я обычно просматриваю макет до старта, собираю вопросы одним списком и фиксирую спорные моменты. Для предварительной оценки достаточно ссылки на Figma — остальное можно уточнить до начала разработки.