Чтобы передать макет разработчику без догадок, проверьте полноту экранов, зафиксируйте сетку, размеры, типографику и состояния компонентов, покажите адаптивное поведение и приложите нужные файлы. Подготовка макета для верстки должна дать разработчику понятную спецификацию дизайна сайта: что собрать, как интерфейс реагирует на действия пользователя и где взять материалы.
Что разработчику важно узнать из макета
- Какие страницы, экраны и сценарии входят в задачу.
- Как устроены сетка, размеры контейнеров и отступы.
- Какие состояния есть у интерактивных компонентов.
- Какие шрифты, цвета и графические материалы использовать.
- Как интерфейс меняется на разных ширинах экрана.
- Где находятся исходный макет, экспортированные файлы и пояснения.
Проверьте целостность макета перед передачей
Проверка нужна дизайнеру, который завершил макет сайта или приложения и готовит передачу макета разработчику. Она особенно полезна перед началом верстки и при передаче работы другому специалисту. Не фиксируйте как окончательные решения экраны, которые еще обсуждаются: сначала отметьте спорные места и согласуйте их с заказчиком или командой.
Пройдите макет как пользователь: откройте основные страницы, проверьте переходы и убедитесь, что для важных сценариев показаны все необходимые состояния. Удалите черновые варианты либо явно пометьте их, чтобы их не приняли за готовый дизайн.
Зафиксируйте сетку, размеры и отступы
Перед началом работы разработчику понадобятся доступ к макету, актуальная версия файлов и сведения о целевых устройствах или ширинах экранов. Подготовьте их заранее:
- предоставьте доступ к файлу в редакторе дизайна с правами просмотра и измерения;
- обозначьте основные брейкпоинты или размеры экранов, для которых подготовлены макеты;
- покажите ширину контентной области, колонки и правила расположения блоков;
- уточните отступы между секциями, элементами и краями контейнера;
- подготовьте исходники изображений, иконок и шрифтов, если их нельзя получить через редактор.
Не полагайтесь на измерение "на глаз". Если значение должно быть точным, укажите его в макете или приложенной заметке; если допустим диапазон, объясните правило изменения.
Опишите компоненты и их состояния
Используйте следующий порядок, чтобы разработчик мог последовательно разобрать интерфейс и не восстанавливал поведение по отдельным картинкам.
-
Сгруппируйте повторяющиеся элементы.
Выделите кнопки, поля, карточки, навигацию и другие элементы, которые встречаются на нескольких экранах. Укажите, какие варианты относятся к одному компоненту. -
Покажите состояния.
Для интерактивного элемента подготовьте примеры доступных состояний: обычного, при наведении или фокусе, отключенного, выбранного либо ошибочного - в зависимости от поведения интерфейса. -
Опишите реакцию на действие.
Уточните, что происходит после нажатия, отправки формы, выбора пункта или закрытия окна. Не оставляйте критичное поведение только в комментариях без связи с конкретным экраном. -
Добавьте недостающие сценарии.
Покажите, как выглядит интерфейс при пустом результате, ошибке, загрузке или длинном содержимом, если такие ситуации возможны в продукте. -
Свяжите состояния с экранами.
Используйте понятные названия страниц и компонентов, а рядом с макетом оставьте короткие пояснения по нестандартным решениям.
Быстрый режим
- Убедитесь, что все нужные экраны и сценарии включены.
- Отметьте сетку, размеры, отступы и целевые ширины.
- Покажите интерактивные состояния и реакции элементов.
- Проверьте визуальные токены, адаптивность и доступы к материалам.
Согласуйте типографику, цвета и визуальные токены
Перед передачей проверьте, что правила оформления можно применить последовательно, а не только скопировать с одного экрана.
- Названия и начертания используемых шрифтов указаны или доступны в файлах.
- Для текстовых стилей понятны размер, насыщенность, межстрочный интервал и назначение.
- Цвета повторно используемых элементов обозначены единообразно.
- Для состояний компонентов предусмотрены нужные варианты цвета и контраста.
- Правила оформления заголовков, основного текста и подписей не противоречат друг другу.
- Радиусы, обводки, тени и другие повторяющиеся свойства заданы последовательно.
- В макете нет случайных локальных значений, которые выглядят как утвержденные токены.
Если проект использует дизайн-систему, свяжите макет с ее актуальными стилями и компонентами. Если общей библиотеки нет, соберите краткое описание повторяющихся параметров в файле или комментариях.
Покажите поведение интерфейса на разных экранах
Для адаптивной верстки важны не только отдельные изображения экранов, но и правила перехода между ними. Проверьте, что в макете объяснено, какие блоки перестраиваются, скрываются, переносятся или меняют порядок.
- Показан только один размер экрана, а поведение на других оставлено на усмотрение разработчика.
- Неясно, как меняются колонки, ширина контейнера и боковые отступы.
- Для меню, таблиц, карточек или длинных заголовков не предусмотрено компактное состояние.
- Не описано, какие элементы скрываются, а какие остаются доступными.
- Макет не учитывает длинный текст, отсутствие изображения или другой объем содержимого.
- Состояния интерфейса на узком экране расходятся с логикой основного сценария.
Если отдельный макет для каждого размера не подготовлен, запишите правила поведения словами и приложите пример для наиболее сложного случая.
Подготовьте файлы и ссылки для быстрого старта
Выберите способ передачи с учетом процесса команды и сложности проекта:
- Ссылка на редактор дизайна. Подходит, когда разработчик может измерять элементы и просматривать комментарии прямо в макете.
- Макет с пояснениями. Уместен для проекта с нестандартными сценариями: добавьте заметки рядом с соответствующими экранами и компонентами.
- Отдельная папка с ресурсами. Используйте ее, если нужны исходники изображений, иконок или другие материалы, которые неудобно получать из редактора.
- Краткое техническое задание на разработку сайта. Приложите его, когда вместе с визуальной частью требуется зафиксировать состав страниц, интеграции, ограничения и критерии приемки.
В сообщении о передаче укажите, какая версия макета актуальна, где смотреть спецификацию и кому задавать вопросы по спорным решениям. Перед отправкой проверьте доступы и откройте ссылки так, как их будет открывать разработчик.
Разбор нюансов передачи макета в разработку
Нужно ли описывать очевидные отступы?
Да, если точное значение влияет на сетку, повторяемость компонентов или адаптивность. Для декоративных и несущественных деталей достаточно ясного визуального правила.
Что делать, если дизайн еще меняется?
Отметьте нестабильные экраны и решения, которые нельзя считать финальными. Передайте разработчику согласованную часть и отдельно обозначьте, что будет уточнено.
Обязательно ли готовить макеты всех размеров?
Нет, если команда согласовала правила адаптации по основным примерам. Однако нестандартное поведение на узком экране лучше показать явно или описать текстом.
Какие состояния компонентов нужно показывать?
Покажите состояния, которые меняют внешний вид или поведение элемента: например, фокус, отключение, ошибку и выбор. Набор зависит от сценария конкретного компонента.
Можно ли передать только ссылку на редактор?
Можно, если у разработчика есть доступ к просмотру и измерению, а в макете достаточно информации о поведении. Исходники, которые нельзя получить из редактора, передайте отдельно.
Где хранить пояснения к макету?
Размещайте пояснения рядом с соответствующими экранами или компонентами, а общие правила соберите в одном заметном месте. Так меньше риск потерять контекст при чтении отдельных страниц.
Как понять, что макет готов к передаче?
Проверьте полноту экранов, ясность размеров и состояний, адаптивные правила, материалы и доступы. Разработчик должен понимать, где взять актуальные файлы и как уточнить неоднозначное поведение.
Автор: Дмитрий Кузнецов.