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