Согласование макетов — этап, на котором чаще всего буксуют проекты. Дизайн вроде готов, но правки идут волнами: то один человек со стороны заказчика вспомнил про блок, то другой захотел «поживее», то выяснилось, что мобильную версию никто не смотрел. Круги переделок растягивают сроки, съедают бюджет и портят отношения ещё до старта разработки.
Эта статья — о том, как выстроить прототипирование и согласование так, чтобы дойти до утверждённых макетов быстро и без конфликтов: чем прототип отличается от дизайна, в каком порядке двигаться, как учесть специфику 1С-Битрикс и как фиксировать договорённости. Материал — для тех, кто заказывает или ведёт разработку сайта. Системный подход к процессу — часть нашей работы над сложными проектами вроде автоматизации на 1С.
Коротко
- Прототип отделяет структуру от оформления; исправить его в разы дешевле, чем готовый дизайн.
- Двигайтесь по этапам: структура на прототипе, потом визуал на макете — не смешивая.
- Назначьте одного ответственного за приёмку со стороны заказчика, иначе правки противоречат друг другу.
- Фиксируйте согласования письменно и с версиями, договоритесь о числе раундов правок.
Почему согласование срывает сроки
Главная причина буксующего согласования — смешивание уровней и отсутствие фиксации. Когда заказчику показывают сразу готовый дизайн, обсуждение уходит в цвета и шрифты, хотя не решена структура; когда правки собирают потоком из разных чатов и людей, они противоречат друг другу; когда договорённости не записаны, к решённому возвращаются снова и снова.
Второй фактор — размытая ответственность на стороне заказчика. Если макет по очереди смотрят пять человек и каждый вносит своё, исполнитель попадает в бесконечный цикл взаимоисключающих правок. Оба фактора устраняются процессом: правильной последовательностью этапов, одним ответственным за приёмку и письменной фиксацией. Об этом и вся статья.
Прототип, макет, дизайн: не путать
Терминологическая путаница сама по себе рождает проблемы, поэтому договоримся о понятиях.
| Артефакт | Что показывает | Что обсуждаем |
|---|---|---|
| Прототип (wireframe) | Блоки, структуру, логику | Что где и как ведёт пользователя |
| Дизайн-макет | Цвета, шрифты, картинки | Визуальное решение и стиль |
| Вёрстка / шаблон | Реальную страницу в браузере | Поведение, адаптив, детали |
Зачем нужен прототип
Соблазн «сразу нарисовать красиво» дорого обходится. Прототип отделяет структуру и логику от оформления, и в этом его ценность: на схеме без цветов дёшево обсуждать, какие блоки на странице, что где расположено, как движется пользователь. Исправить прототип — это подвинуть прямоугольники; исправить готовый дизайн — перерисовать, а исправить свёрстанный шаблон — переделать код.
Поэтому прототип экономит бюджет и нервы: ошибки структуры ловятся на самом дешёвом этапе. Когда структура согласована на прототипе, дизайнер рисует уже по утверждённому каркасу, а не гадает, и правок к дизайну кратно меньше. Пропуск прототипа почти всегда оборачивается переделками на дорогих этапах.
Этапы от структуры к дизайну
Здоровое согласование движется от общего к частному, от дешёвого к дорогому:
- Структура сайта. Карта страниц и разделов, логика навигации — до любых экранов.
- Прототипы ключевых страниц. Главная, каталог, карточка, корзина, оформление — блоки и логика.
- Согласование прототипов. Утверждаем структуру и поведение, фиксируем решения.
- Дизайн-макеты. Визуал по утверждённым прототипам — стиль, цвета, типографика.
- Согласование дизайна. Обсуждаем оформление, не переоткрывая структуру.
- Передача в разработку. Утверждённые макеты с критериями приёмки уходят в вёрстку и сборку.
Каждый этап закрывается перед следующим. Возврат на предыдущий уровень допустим, но он должен быть осознанным решением, а не следствием того, что «структуру никто толком не смотрел».
Прототип с учётом 1С-Битрикс
Прототип для сайта на 1С-Битрикс полезно делать с оглядкой на компонентную модель платформы. Каталог, умный фильтр, карточка товара, корзина, оформление заказа — это типовые компоненты со своей логикой и возможностями. Если прототип закладывает то, что дорого или невозможно реализовать штатными средствами, это надо выявить рано, а не на этапе вёрстки.
Хороший прототип учитывает, что часть блоков — стандартные компоненты (их поведение известно и предсказуемо), а часть потребует доработки или отдельного модуля. Это влияет и на оценку сроков, и на бюджет. Если проект предполагает нестандартную логику, её лучше обозначить сразу — сложные доработки на платформе мы разбираем в статьях про разработку модуля Битрикс и модуль для маркетплейса. Учёт платформы на этапе прототипа экономит недели на переделках.
Кто согласует со стороны заказчика
Один из самых недооценённых факторов скорости — кто именно согласует макеты. Если их по очереди смотрят всё новые люди и каждый вносит правки, исполнитель попадает в круг взаимоисключающих требований: маркетолог хочет одно, руководитель другое, коммерческий директор третье.
Решение простое: определить одного ответственного за приёмку со стороны заказчика — человека, который принимает финальное решение. Мнения команды собираются, но проходят через него, и он выдаёт единую консолидированную позицию. Это резко ускоряет согласование и снимает бесконечные круги. Договориться об этом стоит в самом начале, до первого показа макетов.
Как собирать и фиксировать правки
Хаотичные правки из разных чатов — верный путь к путанице. Их собирают структурированно и фиксируют письменно:
- По экранам и блокам. Правки привязаны к конкретному месту макета, а не «вообще».
- В едином списке. Один канал сбора правок, а не десять сообщений в разных мессенджерах.
- С фиксацией решений. Обсудили — записали, что решили, и двинулись дальше.
- С версиями макетов. Каждая итерация сохраняется, видно, что менялось.
Письменная фиксация — не бюрократия, а защита обеих сторон. Она не даёт возвращаться к уже решённому и делает объём работ прозрачным. Устные договорённости «на созвоне» без записи — источник споров на приёмке.
Адаптив и мобильная версия
Мобильную версию нельзя оставлять «на потом». Большая часть трафика идёт с телефонов, и мобильный экран — это не уменьшенный десктоп, а отдельная логика: что показать первым, как свернуть меню и фильтр, как оформить заказ одной рукой. Если мобильные экраны не прототипировать и не согласовать, на этапе вёрстки всплывут неучтённые решения и новые правки.
Поэтому ключевые страницы прототипируют и согласовывают в двух видах — десктоп и мобайл — наравне. Особое внимание уделяют каталогу, фильтру, карточке и оформлению заказа, где мобильная логика заметно отличается. Это тем важнее, что именно на мобильных теряется больше всего конверсии из-за неудобных решений, принятых «по остаточному принципу».
Критерии приёмки макетов
Согласование должно заканчиваться понятным «принято», а не размытым «вроде норм». Для этого заранее договариваются о критериях приёмки: что должно быть в наборе макетов, какие страницы и состояния, какие устройства. Тогда финальное согласование — это проверка по списку, а не новый виток обсуждений.
Полезно фиксировать, что именно передаётся в разработку: набор утверждённых экранов (десктоп и мобайл), состояния элементов (пустые, с ошибкой, загрузка), поведение ключевых компонентов. Чёткие критерии приёмки защищают от ситуации, когда «дизайн готов», но на вёрстке выясняется, что половина состояний не нарисована. Как аккуратно передавать согласованное в разработку и выкатывать, мы разбираем в статье про CI/CD и деплой на Битрикс.
Регламент правок и границы
Чтобы правки не стали бесконечными, границы оговаривают в начале. Регламент отвечает на вопросы: сколько раундов правок входит в этап, что считается правкой в рамках согласованной структуры, а что — новой задачей за отдельную оценку.
Важно различать два разных процесса: доведение до согласованного результата (это часть работы) и изменение самих требований (это новая задача). Когда заказчик после утверждения структуры хочет добавить новый функционал — это не «правка», а расширение объёма, которое оценивается отдельно. Прописанные заранее границы позволяют обсуждать такие ситуации спокойно и без конфликта, потому что правила известны обеим сторонам.
Частые ошибки
- Сразу дизайн без прототипа. Структурные ошибки ловятся на дорогом этапе и переделываются.
- Смешивание уровней. Обсуждают цвета, пока не решена структура экрана.
- Много согласующих. Противоречивые правки от разных людей без единого ответственного.
- Правки потоком. Разрозненные сообщения вместо структурированного списка по блокам.
- Нет фиксации. Устные договорённости приводят к спорам на приёмке.
- Мобильная версия «на потом». Неучтённая мобильная логика всплывает на вёрстке.
- Нет границ правок. Расширение требований выдаётся за «мелкую правку», сроки плывут.
Чек-лист согласования
- Ответственный назначен. Один человек со стороны заказчика принимает финальное решение.
- Этапы разделены. Структура — на прототипе, визуал — на макете, без смешивания.
- Прототипы согласованы. Ключевые страницы утверждены до старта дизайна.
- Платформа учтена. Прототип сверен с возможностями компонентов 1С-Битрикс.
- Мобайл согласован. Ключевые экраны утверждены и в мобильном виде.
- Правки структурированы. Единый список по экранам и блокам, с версиями макетов.
- Решения зафиксированы. Согласования записаны письменно, критерии приёмки прописаны.
- Границы правок оговорены. Число раундов и разница «правка / новая задача» согласованы заранее.
Вывод
Согласование макетов буксует не из-за «капризного заказчика», а из-за отсутствия процесса. Прототип отделяет структуру от оформления и ловит дорогие ошибки на дешёвом этапе; движение по этапам не даёт обсуждению скатиться в цвета раньше времени; один ответственный за приёмку убирает противоречивые правки.
Добавьте письменную фиксацию решений с версиями, отдельное согласование мобильной версии, чёткие критерии приёмки и оговорённые границы правок — и путь от идеи до утверждённых макетов станет предсказуемым. А если прототип с самого начала учитывает возможности компонентов 1С-Битрикс, вы избежите самой болезненной категории переделок — тех, что всплывают уже в разработке.
