Согласование макетов — не формальность и не попытка угодить вкусу клиента. Это рабочий этап, который фиксирует ожидания, сокращает число переделок и доводит дизайн до состояния, готового к вёрстке. Когда процесс выстроен осознанно, макет утверждается быстрее, а спорных правок становится в разы меньше. За годы работы в студии мы убедились: хаотичные правки почти всегда следствие пропущенного или смазанного согласования, а не «сложного заказчика».
Зачем вообще нужно согласование макета
Ключевая цель — убедиться, что дизайнер и заказчик одинаково понимают структуру, смысл и визуальный язык будущего сайта. На практике это позволяет поймать ошибки в логике, контенте и акцентах на ранней стадии, когда переделки ещё дёшевы и быстры. Если же макет сразу уходит в вёрстку без утверждения, любое изменение потом тянет за собой правки кода, а это уже совсем другие трудозатраты.
Согласование становится критичным, когда:
- проект многостраничный и содержит нестандартные блоки;
- со стороны заказчика несколько лиц, принимающих решения;
- на сайте сложный контент, интеграции или нестандартная логика;
- сроки жёсткие, и нужно избежать бесконечных итераций.
Хорошее согласование — это не «понравилось / не понравилось». Это проверка конкретных решений: структуры, иерархии, читабельности, соответствия задаче и готовности к разработке. В нашей практике мы всегда просим заказчика смотреть на макет через призму пользовательской задачи, а не личных предпочтений. Это сразу снимает половину вкусовых споров.
Из каких этапов обычно состоит согласование
В большинстве проектов согласование идёт поэтапно, а не одним финальным показом. Такой подход снижает риск, что заказчик увидит слишком сырой или, наоборот, слишком детализированный дизайн и начнёт оценивать не то, что нужно. Мы в студии придерживаемся чёткой последовательности, которую отточили на десятках проектов.
1. Бриф и фиксация задачи
На старте важно зафиксировать: цель сайта, аудиторию, ключевые пользовательские сценарии, состав страниц, ограничения по контенту, срокам и бюджету. Если этот этап пропущен или размыт, дальше почти любая правка будет выглядеть как «внезапное изменение задачи». Я часто вижу, как новички пропускают бриф или заполняют его формально, а потом удивляются, что заказчик просит переделать главную, потому что «мы вообще-то хотели не так». Бриф — это не анкета для галочки, а рабочий документ, к которому возвращаются на каждом этапе.
2. Прототип или вайрфрейм
Сначала показывают структуру без финальной визуальной полировки. Это может быть схематичный макет страниц, где видны: порядок блоков, логика навигации, расположение CTA, иерархия контента. На этом этапе проще всего спорить не о цвете кнопки, а о том, что именно должен делать пользователь на странице. В студии мы часто делаем вайрфреймы в Figma с реальными текстами, но без детальной графики — так заказчик фокусируется на смысле, а не на эстетике.
3. Дизайн-концепция
После согласования структуры показывают визуальное направление: типографику, стиль иконок, цвета, настроение, примеры ключевых экранов. Часто именно здесь заказчик «влюбляется» в проект или понимает, что визуальный язык не совпадает с ожиданиями. Поэтому лучше показывать не всё подряд, а 1–2 сильных варианта, а не перегружать выбором. Мы обычно готовим два направления: одно ближе к ожиданиям клиента, второе — более смелое, но оба обоснованы задачей. Это помогает избежать ситуации, когда заказчик говорит «всё не то», а мы не понимаем, куда двигаться.
4. Согласование основных страниц
Обычно утверждают главную страницу и 2–3 типовых внутренних. Этого достаточно, чтобы понять логику всего сайта и не рисовать вручную каждую страницу с нуля до бесконечности. Если проект крупный, мы добавляем ещё один-два уникальных шаблона, но никогда не гонимся за полным набором страниц на этапе дизайна — это задача для системы компонентов, которая появится позже.
5. Финальные правки и подготовка к верстке
Когда концепция утверждена, дизайнер вносит финальные правки, проверяет состояния элементов (ховеры, фокусы, ошибки), готовит адаптивы и передаёт макеты разработчику. Важно, чтобы на этом этапе не всплывали новые смысловые правки — только микро-корректировки. Мы всегда фиксируем версию макета и список изменений, чтобы верстальщик понимал, что именно ушло в работу.
Как выглядит нормальный процесс согласования
Ниже — рабочая схема, которой мы придерживаемся в агентстве. Она помогает и дизайнеру, и заказчику видеть, на каком этапе находится проект и что именно сейчас обсуждается.
| Этап | Что показывает дизайнер | Что должен проверить заказчик | Результат |
|---|---|---|---|
| Бриф | Цели, аудитория, задачи | Правильно ли понята задача | Зафиксированная исходная договоренность |
| Прототип | Структура страницы | Логика блоков, сценарии, CTA | Согласована основа сайта |
| Концепция | Визуальный стиль | Соответствие бренду и ожиданиям | Выбранное направление дизайна |
| Экранные макеты | Главная и типовые страницы | Детали, тексты, смысловые акценты | Утвержденные макеты |
| Финализация | Доработанные версии | Последние замечания | Готовность к верстке |
Эту таблицу мы используем как внутренний чек-лист для менеджеров проектов — она не даёт пропустить этап и помогает объяснить заказчику, почему мы не можем сразу перейти к «красивой картинке».
Что именно нужно согласовывать, а что — нет
Одна из частых ошибок — обсуждать на согласовании всё подряд, хотя часть вопросов давно должна быть закрыта на более раннем этапе. Это размывает фокус и затягивает процесс.
Согласовывают
- структуру страницы;
- расположение смысловых блоков;
- визуальную концепцию;
- тексты в ключевых местах;
- состав страниц;
- основные элементы интерфейса;
- адаптацию под мобильные экраны;
- критичные анимации и состояния.
Не стоит выносить на согласование в последний момент
- смену позиционирования проекта;
- новые бизнес-задачи, не учтенные в брифе;
- полный пересмотр контента;
- замену целевой аудитории;
- «а давайте еще одну страницу, потому что придумали».
Если заказчик приносит такие изменения, это уже не правка, а пересборка части проекта. И это важно честно называть. Был случай, когда на финальном этапе клиент захотел добавить личный кабинет с историей заказов, хотя изначально речь шла о простом лендинге. Мы остановили согласование, вернулись к брифу и пересмотрели бюджет и сроки — иначе проект превратился бы в бесконечный долгострой.
Как правильно показывать макет заказчику
Показ макета — это отдельная управленческая задача. Если просто отправить ссылку и написать «посмотрите», можно получить хаотичный набор замечаний, которые сложно собрать в единый список. В студии мы никогда не отправляем просто ссылку. Мы записываем короткий скринкаст с голосовым пояснением логики экрана — это снимает до 30% вопросов ещё до того, как заказчик начнёт писать правки.
Лучше делать так:
- заранее обозначить, что именно сейчас согласуется;
- показать не весь сайт сразу, а конкретный этап;
- дать контекст: какая задача решается и почему решения такие;
- попросить собирать обратную связь в одном месте (например, в Figma-комментариях или в едином документе);
- назначить срок на ответ.
Полезный формат комментариев: хороший комментарий содержит, что именно не устраивает, почему это важно и что заказчик предлагает вместо этого. Например, не «не нравится шрифт», а «шрифт слишком строгий для нашего бренда, нужен более дружелюбный характер, но без потери читаемости». Такой подход превращает вкусовщину в конструктивное обсуждение.
Какие вопросы стоит задать заказчику на согласовании
Чтобы не гадать, полезно заранее направить обсуждение. Мы даём этот список вопросов стажёрам как шпаргалку для первой встречи с клиентом.
- Что на странице должно быть самым заметным?
- Понятна ли структура без пояснений?
- Есть ли блоки, которые вызывают вопросы?
- Достаточно ли ясно, что делать пользователю дальше?
- Соответствует ли визуальный стиль бренду?
- Нет ли перегруза?
- Чего не хватает для уверенного перехода к верстке?
Такие вопросы помогают выйти за рамки вкусовщины и обсуждать макет как рабочий инструмент. Они же часто вскрывают скрытые ожидания, которые заказчик не озвучил в брифе.
Типовые ошибки при согласовании макетов
1. Обсуждение дизайна без брифа
Если задачи не зафиксированы, спор идёт не о макете, а о разных представлениях о проекте. Это самая частая проблема у новичков: они сразу садятся рисовать, а потом оказывается, что заказчик представлял себе совсем другой продукт.
2. Слишком ранний показ «почти готового» дизайна
Когда заказчик видит красиво оформленный, но ещё сырой экран, он начинает оценивать детали, хотя структура не утверждена. Мы стараемся показывать вайрфреймы в монохроме, чтобы не провоцировать обсуждение цветов и шрифтов раньше времени.
3. Отсутствие версии и фиксации изменений
Без нумерации макетов и истории правок легко запутаться, что именно уже утверждено. В студии мы всегда ведём журнал версий: v1.0, v1.1 и т.д., с кратким описанием изменений. Это спасает, когда через неделю заказчик говорит: «А мы же договаривались по-другому».
4. Слишком много людей в согласовании
Чем больше участников, тем выше риск противоречивых правок. Лучше заранее определить, кто даёт финальное решение. Мы просим заказчика назначить одного ответственного, который агрегирует все замечания и ставит подпись.
5. Правки «на словах»
Если замечание не зафиксировано письменно, позже его можно трактовать по-разному. Все значимые изменения должны оставаться в переписке или в документе. Даже после устного созвона мы всегда отправляем краткое резюме договорённостей.
Как сократить число правок
Вот рабочие приёмы, которые действительно помогают. Мы внедрили их после нескольких проектов, где количество итераций зашкаливало.
- Сначала согласовывать структуру, потом визуал.
- Показывать не больше 1–2 концепций.
- Собирать референсы до начала дизайна — это помогает синхронизировать визуальные ожидания.
- Фиксировать список того, что входит в этап, а что нет.
- Отдельно проговаривать мобильную версию — часто именно она вызывает больше всего споров.
- Сразу обозначать дедлайн на комментарии.
- Делать промежуточные показы, а не копить всё до финала.
- Проводить внутреннее дизайн-ревью перед показом клиенту — свежий взгляд коллеги ловит очевидные ляпы.
Пошаговый алгоритм согласования
Для дизайнера
- Зафиксируйте задачу и границы этапа.
- Подготовьте прототип или схему страниц.
- Согласуйте структуру до визуальной полировки.
- Покажите концепцию и объясните логику решений.
- Соберите комментарии письменно.
- Разделите правки на срочные, желательные и выходящие за рамки.
- Внесите изменения и отправьте новую версию с номером.
- Зафиксируйте финальное утверждение.
Для заказчика
- Смотрите макет через призму цели, а не вкуса.
- Проверяйте, решает ли экран задачу пользователя.
- Оценивайте структуру, читабельность и понятность.
- Формулируйте замечания конкретно.
- Не смешивайте правки по дизайну, контенту и стратегии.
- Утверждайте только то, в чём действительно уверены.
Чек-лист: что проверить перед утверждением
- Понятна ли цель страницы?
- Видно ли основное действие?
- Логична ли последовательность блоков?
- Не перегружен ли экран?
- Соответствует ли стиль бренду?
- Есть ли читабельность на мобильных экранах?
- Все ли важные тексты и элементы на месте?
- Нет ли противоречий между дизайном и контентом?
- Зафиксирована ли финальная версия?
Этот чек-лист мы повесили в рабочем чате команды — он помогает быстро проверить макет перед отправкой заказчику и не упустить типовые проблемы.
Что делать, если заказчик «не может принять макет»
Такое бывает, и причина не всегда в самом дизайне. Обычно проблема в одном из трёх сценариев:
- задача изначально не была точно сформулирована;
- заказчик не видит разницу между этапами и хочет сразу финал;
- в проекте несколько стейкхолдеров с разными ожиданиями.
В этом случае помогает не спор, а возврат к брифу и логике этапов. Полезно спокойно показать:
- какая задача была согласована;
- что уже утверждено;
- какие изменения выходят за рамки текущего этапа;
- что будет, если их всё же внести (сдвиг сроков, увеличение бюджета).
Однажды мы потратили три итерации на переделку главной страницы, пока не вернулись к брифу и не выяснили, что у заказчика изменился состав продукта. После фиксации новых вводных макет утвердили с первого раза. Иногда лучший способ ускорить процесс — не рисовать ещё одну «улучшенную» версию, а сначала вернуть разговор в рамки исходной задачи.
FAQ
Сколько кругов правок нормально закладывать?
Обычно 2–3 итерации достаточно, если задача хорошо зафиксирована заранее. Больше — признак размытых требований или изменений по ходу проекта. В наших договорах мы всегда прописываем количество итераций, чтобы избежать бесконечного процесса.
Что утверждается первым: структура или визуал?
Сначала структура, потом визуальная часть. Иначе можно согласовать красивый, но неудобный сайт. Это правило мы не нарушаем даже при очень сжатых сроках.
Нужно ли утверждать мобильную версию отдельно?
Да. На мобильном экране часто меняются приоритеты, порядок блоков и поведение интерфейса. Мы всегда показываем адаптивы ключевых страниц до финального утверждения.
Можно ли согласовывать макет только в переписке?
Можно, если вся переписка структурирована и фиксирует конкретную версию. Но лучше, чтобы у проекта был единый канал или документ с итогами. Мы используем Figma-комментарии и сводный гугл-док, чтобы ничего не потерялось.
Что делать, если заказчик просит изменения после утверждения?
Сначала определить, это исправление ошибки или новая задача. Если это новая задача, её лучше оформить отдельно, чтобы не размывать границы этапа. Мы обычно говорим: «Это отличная идея, давайте зафиксируем её для следующей итерации или отдельного этапа».
Вывод
Согласование макетов сайта — это управляемый процесс, а не проверка вкуса. Чем раньше зафиксированы задачи, структура и критерии результата, тем спокойнее проходит работа и тем меньше шансов уйти в бесконечные правки. Хороший макет утверждается не потому, что всем «просто понравилось», а потому что он решает задачу, понятен пользователю и готов к следующему этапу разработки. Если выстроить систему с чёткими этапами, письменной фиксацией и разделением зон ответственности, согласование перестаёт быть болью и становится рабочим инструментом, который экономит время и нервы всем участникам.