Сколько итераций правок — это нормально для дизайн-проекта

Коротко: для большинства дизайн-проектов нормой считаются 2–3 раунда правок, зафиксированных в брифе или договоре. Всё, что сверх этого лимита, — либо платный дополнительный раунд, либо повод пересмотреть исходное ТЗ, а не бесконечно дорабатывать макет «пока не понравится». Эта цифра не произвольная: именно столько итераций обычно нужно, чтобы снять расхождения в ожиданиях, не превращая процесс в затяжной цикл без конца. Если на проекте уже заметно, что согласование буксует дольше этого, стоит разбираться не с макетом, а с процессом приёмки — этим как раз занимается команда, которая проводит IT-аудит процесса согласования, когда нужно понять, где именно теряется время между подрядчиком и заказчиком.

Почему «просто дорабатывать, пока не понравится» не работает

Формулировка «дорабатываем, пока не устроит» звучит клиентоориентированно, но на практике убирает единственный механизм, который держит проект в рамках, — лимит. Без него каждая новая правка не закрывает предыдущую, а добавляется к списку: правки накапливаются, противоречат друг другу, и в какой-то момент уже невозможно сказать, какая версия макета финальная, а какая — отменённая. Это классический скоуп-крип: исходная задача постепенно подменяется бесконечным потоком мелких уточнений, каждое из которых по отдельности звучит разумно. Команда при этом работает не менее усердно, чем на проекте с чёткими границами, но результат согласования растягивается в разы, а дизайнер теряет ощущение, когда проект вообще можно считать завершённым.

Сколько раундов правок закладывать в проект

Практическая норма — 2–3 раунда, но конкретное число зависит от масштаба работы. Для одного экрана или баннера обычно достаточно 1–2 итераций: задача узкая, пространство для расхождений небольшое. Для посадочной страницы или лендинга разумны 2–3 раунда — первый снимает крупные замечания по структуре, второй и третий доводят детали. Для многостраничного сайта или мобильного приложения с несколькими экранами итераций может быть больше, но тогда их стоит разносить по этапам: отдельный лимит правок на этап прототипа, отдельный — на финальную отрисовку, а не один общий счётчик на весь проект. Ключевое правило одинаковое для любого масштаба: число раундов фиксируется заранее, до старта работы, а не определяется по ходу дела — иначе лимит просто не будет работать как ограничитель.

Когда правка — это правка, а когда — новая задача

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

Что делать, если лимит итераций превышен

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

Кто должен фиксировать правки, чтобы раунды не размножались

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

Чек-лист — сколько правок нормально для вашего проекта

Эти четыре критерия помогают оценить разумный лимит до старта, а не подгонять его по ходу работы.

• Тип и масштаб проекта: баннер или экран — 1–2 раунда, лендинг — 2–3, многостраничный проект — лимит по этапам, а не один общий.
• Бюджет и формат оплаты: фиксированная цена предполагает жёсткий лимит, почасовая работа — более гибкий, но тоже с порогом, после которого счёт растёт.
• Сложность задачи: чем больше заинтересованных сторон и чем менее очевиден результат на старте, тем выше разумный лимит — но не бесконечный.
• Лимит зафиксирован в брифе или договоре письменно, а не обсуждён устно — иначе на третьем раунде никто не вспомнит, что он вообще был.

Про тактики, которые используют команды, чтобы согласование не превращалось в бесконечный обмен сообщениями, подробно писали и на Хабре — разбор во многом совпадает с тем, что показывает практика работы с правками на стороне подрядчика.