Как давать правки дизайнеру, чтобы не переделывать по кругу

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

Почему правки ходят по кругу

Типичный круг выглядит так. Заказчик просит сделать логотип крупнее. Логотип растёт, шапка становится выше, и на телефоне кнопка заявки уезжает с первого экрана. Следующая правка — «поднимите кнопку». Её поднимают за счёт заголовка, и теперь мелким стал заголовок. Каждая правка лечит следствие предыдущей, а исходная проблема — допустим, плохо читается название компании — так и не прозвучала.

Ещё причины лишних кругов:

• замечания приходят от разных людей и противоречат друг другу;
• правки присылают частями: сегодня по первому экрану, через три дня — по остальным;
• структуру начинают менять, когда дизайн уже нарисован.

Правка — это проблема, а не готовое решение

Дизайнер видит макет целиком и понимает, как одно изменение отзовётся на остальных. Заказчик знает бизнес и своих покупателей. Хорошая правка соединяет эти знания: заказчик описывает, что мешает и почему, а как это исправить, решает дизайнер.

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

Если у вас есть идея решения, предложите её как вариант: «может, сделать кнопку контрастнее?». Дизайнер сделает так или предложит другое решение и объяснит почему. И отмечайте то, что понравилось, — тогда это не потеряется в следующей версии.

Плохая правка	Хорошая правка
«Сделайте кнопку красной»	«Непонятно, что это кнопка: она сливается с фоном, и её легко пролистать»
«Шрифт покрупнее»	«На телефоне цены в карточках приходится разглядывать — мелко и бледно»
«Не нравится»	«Получилось строго, как у банка, а к нам приходят за домашней атмосферой»
«Сделайте как у конкурента»	«У конкурента цены видны сразу, а у нас до них три экрана, хотя о цене спрашивают в первую очередь»
«Поменяйте фото»	«На фото не узнать наш зал — похоже на снимок из фотобанка»
«Логотип побольше»	«Название в шапке почти не читается, а по нему нас ищут после рекомендаций»
«Переделайте первый экран»	«С первого экрана непонятно, что мы продаём: красивое фото есть, а предложения нет»
«Добавьте воздуха»	«Блок услуг читается сплошным текстом — не видно, где кончается одна услуга и начинается другая»

Как собрать правки: один список, один человек, приоритеты

Один ответственный. Макет смотрят директор, маркетолог, менеджер по продажам — и у каждого своё мнение. Если все пишут дизайнеру напрямую, он получает «построже» и «поярче» одновременно и вынужден угадывать, кого слушать. Пусть замечания собирает один человек: он договаривается с коллегами, убирает противоречия и отправляет итог. Лучше, если он же принимает решения или может быстро их получить.

Один список. Не голосовые и не пересланные сообщения из трёх чатов, а один документ или комментарии в одном файле. Пункты пронумерованы — тогда дизайнер ответит по номерам: «пункты 1–5 готовы, по шестому есть вопрос». Отправляйте список, когда посмотрели весь макет, а не только первый экран.

Приоритеты. Пометьте каждый пункт:

• критично — ошибка в фактах (цены, телефон, условия) или то, что мешает цели страницы: не видно кнопки, непонятно предложение;
• желательно — улучшения, без которых страница всё равно работает;
• вопрос — не уверены, что это проблема, и хотите услышать объяснение.

Так дизайнер начнёт с главного, а спор о «желательном» не задержит остальное.

Как смотреть макет и где оставлять комментарии

Мобильный макет — на телефоне. На большом мониторе он кажется просторным, текст — читаемым, кнопки — крупными. В руке всё иначе: мелкий текст становится мелким по-настоящему, до кнопки нужно дотянуться большим пальцем, а на улице экран бликует. В приложении Figma для телефона можно открыть прототип на весь экран и оставить комментарий прямо оттуда. Что ещё проверить на узком экране, — в статье про адаптивный дизайн.

Комментарии в Figma. Если макет в Figma, оставляйте правки прямо на нём: нажмите C или значок комментария, щёлкните по нужному месту и напишите замечание. Комментарий привяжется к этому месту, дизайнер ответит в той же ветке и отметит его решённым, когда исправит. Нужен бесплатный аккаунт Figma и доступ к файлу хотя бы на просмотр.

Скриншоты. Если макет не в Figma — скриншот с рамкой или стрелкой и номер пункта из списка. Один скриншот — одна правка. Место подписывайте словами: «главная, блок с ценами, вторая карточка», а не «там внизу».

Какие правки уместны на каждом этапе

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

• Прототип — структура и смысл: какие блоки, в каком порядке, что в них сказано, куда ведут кнопки. Что в нём проверять, — в статье о прототипе сайта.
• Дизайн — то, как всё выглядит: цвета, шрифты, фотографии, акценты, вид кнопок и карточек. Структура к этому моменту уже утверждена.
• Разработка — расхождения с утверждённым макетом и ошибки: что-то съехало, не отправляется форма, не открывается меню. Новый вид блока здесь — уже не правка.

Правка или новая задача: в чём разница

Правка приближает результат к тому, о чём договорились: к брифу, техническому заданию, утверждённому прототипу. «Кнопку не видно», «цена неверная», «на телефоне съехал заголовок» — это правки.

Новая задача меняет саму договорённость: другая аудитория, новый раздел, онлайн-запись, которой не было в плане, английская версия, «давайте попробуем совсем другой стиль». Так бывает — бизнес меняется, — но это новый объём работы, а значит, новая оценка и новый срок. Честнее назвать такое изменение своим именем, чем выдавать его за «небольшую правку». Провести границу проще, когда договорённости записаны, например в техническом задании.

Сколько кругов правок. Число кругов на каждом этапе и то, что считается одним кругом, стоит оговорить в договоре до начала работы. Удобно считать кругом один сводный список и одну доработку по нему. Такое правило защищает обе стороны: заказчик знает, на что рассчитывать, а дизайнер — что макет не будут переделывать бесконечно.

Вкусовые споры: что делать, если «не нравится»

«Нравится» и «не нравится» — нормальная реакция, но сайт делают не для владельца, а для его покупателей. Когда спор упирается во вкус, вернитесь к двум вопросам: кто будет смотреть сайт и что он должен сделать. «Синий или зелёный?» — вопрос без ответа. «Какой цвет скорее вызовет доверие у родителей, которые выбирают детский центр?» — уже предмет для разговора.

Попросите дизайнера объяснить решение: хорошее решение обосновано задачей, а не модой. Если каждый остаётся при своём, покажите оба варианта нескольким людям из вашей аудитории — не коллегам и не родственникам — и дайте им задание: найти цену, записаться. Смотрите, с каким вариантом они справились быстрее, а не какой им больше понравился.

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

Частые ошибки

• Правки голосовыми сообщениями в разных чатах.
• «Сделайте красиво» вместо описания проблемы.
• Правки частями: сегодня первый экран, завтра подвал.
• Мнения всех коллег переслали дизайнеру, не сведя их в один список.
• Мобильный макет оценили на мониторе.
• Структуру меняют на этапе дизайна.
• Новый раздел выдают за «небольшую правку».

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