Передача макетов без стресса: как дизайнеру говорить с разработчиком на одном языке

«Я нарисовал как надо, а разработчики сделали не так». «Дизайнер придумал красоту, которую невозможно реализовать». Эти фразы звучат в каждом втором проекте, где дизайнеры и разработчики работают отдельно друг от друга.

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

Разберем по этапам, как выстроить работу так, чтобы макет превратился в рабочий продукт без потерь.

Этап 1. До начала визуализации — техническое согласование

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

Что обсудить на старте:

На какой платформе или фреймворке будет реализация (WordPress, React, Vue, custom CMS)
Есть ли готовые компоненты или библиотеки, которые можно использовать
Какие анимации технически возможны без перегрузки сайта
Адаптивность: под какие разрешения экранов нужны макеты (десктоп, планшет, мобильный)
Есть ли ограничения по шрифтам (лицензии, поддержка кириллицы, веб-версии)

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

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

Этап 2. Создание макета — думать о реализации

Когда дизайнер рисует макет, он должен держать в голове, что кто-то будет это воплощать в коде. Некоторые вещи, которые выглядят логично в Figma, становятся проблемой при вёрстке.

Принципы «разработчико-ориентированного» дизайна:

Сетка и выравнивание. Если элементы расположены хаотично (кнопка на 237 пикселях от края, другая — на 241), разработчик потратит время, чтобы понять, это задумка или ошибка. Используйте модульную сетку с четкими отступами.
Повторяющиеся элементы. Если на сайте 10 страниц, и на каждой кнопка выглядит по-разному (разные отступы, шрифты, цвета) — это не вариативность, а хаос. Разработчику придется создавать отдельный стиль для каждой кнопки. Лучше создать компоненты и использовать их последовательно..
Состояния интерактивных элементов. Кнопка не существует в одном виде. У нее есть обычное состояние, при наведении, при нажатии, неактивное. Если в макете показано только одно состояние, разработчик будет додумывать остальные сам.
Реалистичный контент. Не рисуйте заголовок в две строки, если в реальности он может быть в пять. Не вставляйте текст Lorem Ipsum длиной 50 символов, если реальные описания будут по 300. Макет должен учитывать крайние случаи.

Этап 3. Подготовка макета к передаче — чек-лист

Перед тем как отправить макет разработчикам, его нужно подготовить. Чем структурированнее файл, тем меньше вопросов и правок.

Чек-лист для передачи макета

Что проверить	Зачем это важно
Все слои названы понятно	Разработчик должен понимать, что это за элемент, не гадая
Слои сгруппированы логично	Навигация по макету занимает секунды, а не минуты
Удалены скрытые и лишние слои	Файл не захламлен старыми версиями и экспериментами
Шрифты и цвета вынесены в стили	Разработчик видит системность, а не 15 оттенков одного цвета
Экспортированы все иконки и изображения	Разработчику не нужно вырезать их из макета самостоятельно
Указаны отступы и размеры ключевых элементов	Не нужно измерять все линейкой

Хороший макет — это когда разработчик открывает файл и сразу понимает структуру. Плохой — когда приходится искать нужный элемент среди 200 слоев с названиями «Rectangle 47 copy 3».

Этап 4. Передача макета — что нужно кроме файла

Передать файл Figma или Sketch недостаточно. Разработчику нужен контекст: что где, как это должно работать, какие есть нюансы.

Что передавать вместе с макетом

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

Описание интерактивных элементов. Что происходит при наведении на кнопку? Как открывается модальное окно? Куда ведет ссылка? Это можно описать текстом или сделать интерактивный прототип.

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

Шрифты и ресурсы. Файлы шрифтов (если это не стандартные веб-шрифты), иконки в нужных форматах (SVG, PNG), изображения в правильном разрешении.

Комментарии к сложным моментам. Если есть нестандартное поведение элемента или особая логика — лучше написать это прямо в макете или в отдельном документе.

Этап 5. Обсуждение макета — синхронизация перед стартом

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

О чем говорить на встрече:

Пройтись по структуре. Показать логику страниц, как они связаны, какие блоки повторяются.
Обсудить сложные элементы. Если есть нестандартная анимация, параллакс, сложная форма — уточнить, как это будет реализовано.
Согласовать приоритеты. Что критично реализовать в точности, а где допустимы компромиссы.
Уточнить сроки. Разработчик оценит объем работы, скажет, сколько времени займет каждая страница. Если сроки не укладываются, можно обсудить, что упростить или отложить на вторую очередь.

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

Этап 6. Проверка верстки — что сверять с макетом

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

На что обращать внимание:

Шрифты и типографика. Совпадают ли размеры, начертания, межстрочные интервалы. Часто бывает, что в коде шрифт выглядит чуть крупнее или мельче, чем в макете — это нужно корректировать.
Цвета. Проверить, что все цвета совпадают с оригиналом. Иногда разработчик может ошибиться на пару оттенков, и это заметно.
Отступы и выравнивание. Элементы должны стоять на тех же позициях, что и в макете. Если кнопка в макете по центру, а в верстке чуть левее — это нужно поправить.
Интерактивные элементы. Проверить все состояния: наведение, клик, ошибки в формах. Убедиться, что анимации работают так, как задумано.
Адаптивность. Открыть сайт на телефоне и планшете, проверить, что все корректно отображается. Часто на мобильных вылезают проблемы, которые не видны на десктопе.

Этап 7. Правки и итерации — как давать фидбек

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

Как НЕ надо:

«Что-то не то с кнопкой» (непонятно, что именно)
«Сделайте красивее» (субъективно, нет критериев)
«Как в макете» (разработчик считает, что так и сделал, нужна конкретика)

Как НАДО:

«Кнопка должна быть на 8px выше, сейчас отступ 32px, а нужно 24px»
«Цвет фона кнопки #FF5733, в верстке #FF6744 — поправьте на точный»
«При наведении на кнопку должна быть анимация изменения цвета 0.3s, сейчас ее нет»

Чем конкретнее замечания, тем быстрее они исправляются. Лучше сделать скриншот и разметить стрелками, что не так, чем писать длинное описание.

Инструменты для фидбека:

Комментарии прямо в Figma (если разработчик работает из макета)
Скриншоты с разметкой (можно использовать инструменты вроде Monosnap)
Список правок в общем документе с нумерацией и статусами (сделано/в работе/на проверке)

Этап 8. Финальная приемка — последняя проверка перед запуском

Все правки внесены, сайт готов к запуску. Финальная проверка — это не формальность, а ответственный этап, потому что после запуска исправлять сложнее.

Чек-лист финальной проверки:

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

Если все работает — супер, проект можно запускать!

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

Понравилась статья?