Момент передачи макета из рук дизайнера в руки разработчика — это критическая точка в создании любого цифрового продукта. Казалось бы, всё готово: продумана логика, отрисованы пиксели, утверждён стиль. Но именно на этом этапе рождаются бесконечные правки, недопонимания и срывы сроков. Как превратить этот процесс из головной боли в отлаженный конвейер, где каждый пиксель и взаимодействие точно воплощаются в коде? Давайте разбираться.
Подготовка макета: Фундамент успешной передачи
Хорошая передача начинается не с отправки файла, а с его внутренней организации. Разработчик — не ясновидящий, он видит только то, что вы ему предоставили.
1. Структура и организация слоёв
Представьте, что разработчик заходит в ваш файл Figma, Sketch или Adobe XD. Что он видит? Хаотичную груду слоёв с названиями «Rectangle 234» или «Group copy 5»? Это путь в никуда.
- Нейминг: Называйте слои и группы логично и на английском языке (стандарт индустрии):
header/logo,button/primary,modal/close-btn. - Группировка: Логически группируйте элементы по блокам и компонентам. Используйте папки (frames/artboards).
- Чистота: Удаляйте неиспользуемые, скрытые или дублирующие слои.
Используйте компоненты (Components/Symbols) для повторяющихся элементов: кнопки, карточки, поля ввода. Это не только упростит правки вам, но и даст разработчику чёткое понимание переиспользуемых UI-китов.
2. Работа с типографикой и стилями
Шрифты, размеры, межбуквенные интервалы — здесь важна системность.
- Создайте и используйте текстовые стили для каждого типа текста: H1, H2, Body, Caption и т.д.
- Пропишите не только размер шрифта, но и межстрочный интервал (line-height), часто выраженный в множителе (например, 1.5).
- Укажите используемые шрифты и, что критично, ссылки на них (Google Fonts, ссылка на файл .woff/.ttf).
- Чётко определите иерархию шрифтов в стилевом руководстве (style guide).
Ключевые артефакты для передачи
Один PSD или Figma-файл — это лишь часть пазла. Разработчику нужен контекст и спецификации.
Техническое задание (ТЗ) или User Stories
Макет показывает «как выглядит», но не объясняет «как работает». Приложите даже краткое описание:
- Логика интерактивных элементов (Что происходит при наведении? Куда ведёт кнопка?).
- Состояния элементов (активное, неактивное, загрузка, ошибка, успех).
- Поведение на разных разрешениях (адаптив).
- Логика работы сложных компонентов (слайдеры, фильтры, модальные окна).
Style Guide (Стилевое руководство)
Вынесите на отдельную страницу или в отдельный документ:
- Цветовая палитра с HEX/RGB кодами для каждого цвета. Укажите основной цвет, акцентный, фоновые, цвета текста и состояний (error, success, warning).
- Типографика со всеми стилями текста.
- Набор UI-компонентов: все кнопки, поля ввода, чекбоксы, радиокнопки в их различных состояниях.
- Отступы и сетка (Grid System): Укажите базовый модуль (например, 8px), отступы между крупными блоками, внутренние отступы (padding) элементов.
Используйте инструменты автоматической генерации спецификаций, такие как Figma Inspect, Zeplin, Avocode или Sketch Measure. Они позволяют разработчику одним кликом получать CSS-свойства, расстояния между элементами и экспортировать ресурсы.
Процесс передачи и коммуникация
Файлы отправлены. Что дальше? Начинается этап живого взаимодействия.
1. Проведение брифинга
Никогда не ограничивайтесь просто отправкой файлов по почте или в чат. Проведите короткую онлайн-встречу (брифинг), где:
- Пройдётесь по ключевым экранам и интерактивным сценариям.
- Объясните бизнес-логику и приоритеты.
- Ответите на первоначальные вопросы разработчика.
- Определите точки контроля и сроки проверки первых вёрсток.
2. Выбор канала для вопросов
Договоритесь, где будет происходить оперативное общение (Slack, Telegram, Jira-комментарии) и где фиксируются важные решения (задачи в трекере, email). Это предотвратит потерю информации.
3. Проверка вёрстки (Pixel Perfect)
Разработчик присылает первую версию. Как проверять?
- Используйте overlay: Наложите ваш макет поверх вёрстки в браузере с помощью плагинов (например, PerfectPixel). Это покажет все расхождения.
- Проверяйте на разных устройствах и разрешениях, а не только на своём мониторе.
- Фокусируйтесь на важном: Не требуйте идеального совпадения в 1 пиксель для незначительных элементов. Важнее — сохранение пропорций, отступов, цвета и общего ощущения.
- Формулируйте правки чётко: Вместо «кнопка какая-то не такая» пишите «Увеличить вертикальный padding кнопки «Отправить» с 12px до 14px, цвет фона должен быть #4F46E5, а не #6366F1».
FAQ: Часто задаваемые вопросы
В каком формате лучше передавать макет?
Современный стандарт — ссылка на облачный макет в Figma. Он позволяет работать онлайн, оставлять комментарии, копировать CSS-код и экспортировать ресурсы. Альтернативы: Zeplin (для готовых макетов), Adobe XD, Sketch + InVision.
Нужно ли отрисовывать все состояния элементов?
Да, желательно. Как минимум, для ключевых интерактивных элементов (кнопки, ссылки, поля ввода) покажите состояния: default, hover, active (pressed), focus, disabled, loading. Это сэкономит массу времени на уточнениях.
Как передавать адаптивную вёрстку?
Создавайте отдельные артборды (frames) для ключевых точек останова (breakpoints), например: 320px (мобильный), 768px (планшет), 1280px (десктоп). Покажите, как меняется компоновка блоков, размеры шрифтов и отступы. Не обязательно рисовать все промежуточные состояния, но логика изменений должна быть ясна.
Кто должен готовить графические ресурсы (иконки, изображения)?
Идеально, если дизайнер экспортирует и предоставляет все ресурсы в нужных форматах и размерах (SVG для иконок, WebP/JPEG/PNG для изображений). Указывайте названия файлов логично (icon-search.svg, photo-banner-desktop.jpg). Если ресурсы большие, используйте облачные хранилища или встроенные возможности Figma/Sketch.
Что делать, если разработчик постоянно что-то делает не так?
Скорее всего, проблема в коммуникации. Вернитесь к этапу брифинга, убедитесь, что ТЗ и стилевое руководство понятны. Внедрите чек-лист для проверки вёрстки. Часто «неправильно» — это просто разное видение деталей, которое нужно согласовать один раз и зафиксировать.