Правки при разработке сайта: как мы согласовываем изменения
«Нет, наши клиенты принимают решение не так»,
это серьёзный аргумент.
Мы можем задать дополнительные вопросы, проверить предположение и предложить другую реализацию, но не будем доказывать человеку, что лучше него понимаем его собственный бизнес.
У нас другая экспертиза.
Мы должны правильно перевести знания заказчика о бизнесе в структуру сайта, пользовательские сценарии, UX, тексты, интерфейс и техническое решение.
Именно поэтому перед проектированием мы проводим интервью с ЛПР и другими участниками проекта, а не пытаемся узнать весь бизнес из универсальной анкеты.
Почему мы отказались от классических брифов, отдельно объясняем в статье «Почему мы не используем брифы и жёсткое ТЗ для разработки сайта».
{ссылка на /blog/pochemu-my-ne-ispolzuem-brify-i-zhestkoe-tz}
Но пожелание заказчика и решение задачи — не одно и то же
Представим простую ситуацию.
На макете есть CTA-кнопка.
Заказчик смотрит на неё и говорит:
«Сделайте кнопку больше и красной».
Можно просто сделать.
А можно сначала спросить:
«Зачем?»
Допустим, ответ:
«Мне кажется, сейчас её никто не заметит».
Вот теперь у нас есть не указание, а задача.
Нужно проверить визуальную иерархию и понять, действительно ли целевое действие недостаточно заметно.
Возможно, заказчик прав.
Но решить проблему можно по-разному: изменить контраст, расположение, пространство вокруг элемента, текст CTA, композицию секции или действительно размер кнопки.
Красный цвет — только один из возможных вариантов. И совсем необязательно лучший.
Поэтому мы стараемся обсуждать не саму инструкцию, а её причину.
В этом смысле разговор иногда действительно похож на метод Сократа: последовательно задаём вопросы, пока не добираемся до исходной проблемы.
«Зачем сделать больше?»
«Чтобы заметили».
«Почему сейчас не заметят?»
«Потому что рядом слишком много элементов».
И вот мы уже обсуждаем не размер кнопки, а перегруженную визуальную иерархию.
В этом и заключается существенная разница между подрядчиком, который выполняет указания, и студией, которая несёт ответственность за свои профессиональные решения.
А если «я показал жене, ей не понравился синий»?
Такие аргументы в разработке встречаются чаще, чем может показаться.
Условный пример:
«Я посоветовался с женой, она сказала, что синий будет смотреться некрасиво».
Мы не проигнорируем эту обратную связь. За ней вполне может находиться реальная проблема.
Но сам по себе факт того, что цвет не понравился жене собственника, его другу, бухгалтеру или случайному коллеге, ещё не означает, что цвет необходимо поменять.
Сайт создаётся не для нас.
И не для собственника.
И даже не для его семьи.
Он создаётся для людей, которым компания продаёт продукт.
Поэтому вопрос должен звучать не «нравится ли нам этот синий?», а:
помогает ли выбранное решение решать задачу интерфейса и соответствует ли оно контексту аудитории и бренда?
В дизайне неизбежна субъективность. Мы сами не считаем, что каждое решение можно математически доказать.
Но между субъективностью и случайностью есть большая разница.
Если мы выбрали определённую структуру, CTA, паттерн навигации или визуальную иерархию, мы должны уметь объяснить выбор.
UX-принципами. Анализом конкурентов. Поведением аудитории. Аналитикой. Ограничениями конкретного интерфейса. Предыдущим опытом.
Формулировка «нам просто кажется, что так красивее» — слабая защита решения.
Подробнее о том, как появляются и защищаются наши концепции, — в статье «Как мы принимаем и защищаем решения в дизайне сайта».
{ссылка на /blog/kak-my-prinimaem-i-zashchishchaem-resheniya-v-dizajne-sajta}
Если заказчик прав — мы меняем своё решение
Защита концепции не означает, что студия всегда права.
Иногда во время презентации клиент говорит:
«Вы неправильно поняли наш продукт».
И после нескольких вопросов становится понятно: действительно неправильно.
В такой ситуации нет смысла продолжать защищать исходный вариант только потому, что мы потратили на него время.
Его нужно менять.
Одна из самых опасных вещей в работе подрядчика — влюбиться в собственную концепцию настолько, что сохранение дизайнерского решения становится важнее задачи клиента.
Поэтому мы разделяем две области экспертизы.
Заказчик лучше знает свой бизнес.
Мы можем изучить рынок, провести конкурентный анализ, посмотреть отзывы, поисковые запросы и пользовательские сценарии. Но нескольких недель исследования всё равно недостаточно, чтобы заменить человека, который годами управляет компанией.
Мы лучше знаем свою профессиональную область.
Проектирование интерфейсов, UX, веб-разработка, визуальная коммуникация, техническая реализация — именно за этой экспертизой к нам обращаются.
Хороший проект получается в точке пересечения этих знаний.
Не когда одна сторона безоговорочно подчиняется другой.
Что мы считаем обычной правкой
У нас достаточно простая практическая граница.
Если изменение остаётся внутри согласованной задачи, не создаёт существенного нового объёма работ и не меняет бюджет или сроки проекта, обычно мы рассматриваем его как правку.
Например:
- скорректировать текст или формулировку;
- поменять отдельные элементы палитры;
- изменить расположение нескольких секций;
- поправить элементы интерфейса;
- уточнить уже согласованное содержание.
Такие изменения являются естественной частью работы над сайтом.
Формально в договоре у нас предусмотрено количество итераций правок по этапам. Это необходимо прежде всего как защита от злоупотребления ресурсами команды.
Но договор и реальная ежедневная коммуникация — не одно и то же.
Когда мы с заказчиком нормально работаем над общей задачей, мы не открываем договор после каждой просьбы поменять два слова и не считаем каждую небольшую корректировку отдельной услугой.
Лимит нужен для пограничной ситуации.
Не для того, чтобы заработать на каждой правке.
Где заканчивается правка и начинается новая задача
Есть принципиальная разница между:
«Давайте изменим этот блок»
и
«Давайте добавим то, чего изначально в проекте не было».
Представим, что в начале разработки договорились: заявки с сайта отправляются на email.
В середине проекта заказчик внедряет новую CRM и говорит:
«Давайте теперь все заявки автоматически создавать там, распределять по менеджерам и передавать источники».
С точки зрения пользователя это действительно может звучать как небольшая правка.
Для разработки это уже новая интеграция.
Её нужно спроектировать, реализовать, проверить, обработать ошибки и протестировать вместе с CRM.
Другой пример.
Мы согласовали страницу, прошли прототип, дизайн и разработку. В конце появляется решение:
«А давайте полностью удалим вот эту секцию и вместо неё сделаем калькулятор».
Это не ещё одна итерация дизайна.
Это новый функционал.
Похожая ситуация возникает, когда:
- добавляются новые страницы;
- меняется логика пользовательского сценария;
- появляются дополнительные интеграции;
- существенно меняются бизнес-требования;
- утверждённая секция полностью проектируется заново;
- проект получает функциональность, которой не было в первоначальном объёме.
В управлении проектами это обычно называют scope creep — постепенным расширением объёма проекта по сравнению с первоначальными договорённостями.
Само изменение требований не является чем-то плохим.
Бизнес меняется. За время разработки может появиться новая система, продукт, сотрудник или информация о клиентах. Иногда поменять первоначальное решение действительно выгоднее, чем довести до production то, что уже потеряло актуальность.
Проблема возникает только тогда, когда новая задача называется «маленькой правкой» и предполагается, что она никак не влияет на сроки, стоимость и загрузку команды.
Если меняется scope, мы просто должны это признать и отдельно договориться, что делаем дальше.
Почему нельзя бесконечно переделывать уже согласованные этапы
Проект строится последовательно не ради бюрократии.
Сначала мы выясняем требования.
Потом проектируем логику.
Потом согласовываем концепцию.
Потом дизайн.
Потом разработку.
Потом тестируем результат.
Каждый предыдущий этап является фундаментом следующего.
Если во время прототипирования переставить три секции, это может занять немного времени.
Если сделать то же самое после дизайна — нужно менять уже больше материалов.
Если пересмотреть структуру после завершения разработки — изменения затронут дизайн, код, адаптивные версии, тестирование и иногда интеграции.
Поэтому одна и та же идея имеет разную стоимость на разных этапах проекта.
Именно для этого мы показываем промежуточный результат заказчику и согласовываем его до перехода дальше.
Не чтобы потом сказать:
«Вы подписали — теперь ничего менять нельзя».
А чтобы существенные сомнения возникали тогда, когда исправлять их дешевле всего.
{здесь вставить изображение: «Стоимость изменения по этапам — прототип → дизайн → разработка → production»}
Что происходит, если новое замечание противоречит предыдущему
Такое происходит регулярно.
Неделю назад договорились, что определённый блок нужен. Сегодня появляется предложение его убрать.
Мы не воспринимаем это автоматически как проблему.
Сначала выясняем, почему изменилось решение.
Возможно, появилась новая информация.
Компания пересмотрела продукт. Поговорила с клиентами. Получила статистику. Изменила процесс продаж. Подключился ЛПР, который дал важный контекст.
Тогда предыдущую договорённость действительно имеет смысл пересмотреть.
А иногда объективно ничего не изменилось, просто начинается цикл:
«Давайте попробуем так».
Через неделю:
«Нет, вернём как было».
Потом:
«А можно посмотреть третий вариант?»
Именно здесь правки перестают улучшать продукт и начинают расходовать ресурсы проекта.
Наша задача — заметить такой момент и вернуть обсуждение к цели:
Что именно мы сейчас пытаемся улучшить?
Если ответа нет, дополнительная итерация сама по себе вряд ли сделает сайт эффективнее.
А если в проект неожиданно приходит новый ЛПР
Допустим, два месяца сайт согласовывался с маркетологом.
Когда разработка почти закончена, генеральный директор впервые открывает макет и говорит:
«Мне вообще всё не нравится».
Формально проблема выглядит как очередная волна правок.
Фактически это проблема управления проектом.
Если финальное решение принимает генеральный директор, критические концепции нужно было показывать ему значительно раньше.
Поэтому мы стараемся ещё в начале определить ЛПР и презентовать ключевые этапы непосредственно человеку, который действительно может их утвердить.
Если в конце проекта внезапно выяснилось, что всё это время мы согласовывали фундаментальные решения не с тем человеком, часть ответственности лежит и на нас.
Правильный stakeholder management обычно дешевле бесконечной борьбы с комментариями на последнем этапе.
Почему мы вообще ограничиваем количество правок договором
Потому что ресурсы любой команды конечны.
Если один проект начинает постоянно получать новые итерации без ограничений, время забирается не из воздуха.
Оно забирается у других клиентов, разработки, тестирования и задач этого же проекта.
Поэтому договорные ограничения — это не недоверие к заказчику.
Это механизм управления риском.
В абсолютном большинстве нормальных проектов необходимость буквально считать каждую правку вообще не возникает.
Но если проект превращается в бесконечную последовательность субъективных переделок, должна существовать точка, в которой студия может сказать:
согласованный объём работ закончился; дальнейшая переработка требует отдельного решения.
В крайнем случае, если ещё на этапе работы становится понятно, что стороны принципиально несовместимы по подходу и проект будет бесконечно поглощать ресурсы, его разумнее завершить в порядке, предусмотренном договором, чем месяцами поддерживать конфликт.
Плохой проект не становится хорошим только потому, что в него вложили ещё сто часов.
Последнее слово всё равно за заказчиком
Есть важный момент.
Мы можем быть не согласны.
Можем показать аргументы.
Можем предложить другую реализацию.
Можем назначить дополнительную встречу и ещё раз пройти всю логику решения.
Но в конечном счёте сайт принадлежит заказчику.
Если мы объяснили свою позицию, клиент её понял и всё равно сознательно выбирает другой вариант — последнее слово за ним.
Мы реализуем согласованное решение, если оно не создаёт критических юридических, технических или иных ограничений.
Иногда такой проект просто не попадёт в наше портфолио.
И это нормально.
Экспертность подрядчика не даёт ему право забирать у собственника контроль над его бизнесом.
Она создаёт другую обязанность: не молчать, когда считаешь решение плохим.
Нам важно не выиграть спор
Спор между студией и заказчиком не должен заканчиваться со счётом 1:0.
Если дизайнер доказал, что клиент ничего не понимает в интерфейсах, но клиент после встречи чувствует себя идиотом, — это плохая коммуникация.
Если заказчик продавил своё решение только потому, что платит деньги, а студия молча реализовала то, что считает заведомо слабым, — это тоже плохой результат.
Нормальный итог выглядит иначе:
«Мою задачу поняли и нашли решение лучше».
Иногда этим решением будет наш первоначальный вариант.
Иногда — предложение клиента.
А иногда в процессе разговора появляется третий вариант, которого не было ни у одной стороны в начале.
Именно ради последнего мы и предпочитаем обсуждение механическому исполнению правок.
Правки нужны не для того, чтобы сайт понравился всем
Невозможно сделать интерфейс, который одинаково понравится собственнику, маркетологу, дизайнеру, бухгалтеру, супруге директора и каждому потенциальному клиенту.
Да это и не нужно.
Цель разработки — не получить максимальное количество одобрительных кивков на презентации.
Сайт должен выполнять свою функцию для бизнеса и его аудитории.
Поэтому мы смотрим на него через оффер, структуру, пользовательские сценарии, возражения клиентов, UX и целевые действия.
После разработки — ещё и через реальные данные.
Перед запуском мы проверяем формы, адаптивность, браузеры, интеграции, пользовательские сценарии, accessibility и производительность. А если после публикации проект остаётся на сопровождении, уже можно использовать аналитику и CRO, чтобы заменять часть предположений фактическим поведением пользователей.
Подробнее об этом — «Как мы тестируем сайт перед запуском».
{ссылка на /blog/kak-my-testiruem-sajt-pered-zapuskom}
В конечном счёте клиент покупает не право на бесконечные правки
Он покупает результат работы специалистов.
Это принципиальное различие.
Количество итераций само по себе не делает сайт лучше.
Можно двадцать раз передвинуть один блок и получить более слабый результат, чем после первой версии.
Ценность студии заключается не в способности бесконечно выполнять команды мышкой.
Она заключается в том, чтобы разобраться в задаче, предложить решение, аргументировать его, реализовать, проверить и при необходимости признать собственную ошибку.
Мы рассматриваем сайт прежде всего как инструмент бизнеса: продаж, коммуникации, автоматизации и работы с аудиторией.
Поэтому вопрос должен быть не:
«Сколько раз я могу попросить вас всё переделать?»
А:
«Как мы вместе поймём, какое решение здесь лучше?»
Этой теме посвящён отдельный материал «Что на самом деле покупает бизнес, заказывая сайт у студии».
{ссылка на /blog/chto-pokupaet-biznes-zakazyvaya-sajt-u-studii}
Есть задача по сайту? Начнём не с макета
Если вы уже точно знаете цвет каждой кнопки и ищете человека, который буквально воспроизведёт инструкцию, наш подход может оказаться избыточным.
Если же нужна команда, которая разберётся в задаче, будет задавать вопросы, аргументировать решения и при необходимости спорить с вами ради результата — имеет смысл познакомиться.
На первом интервью мы разбираем бизнес, продукт, аудиторию, текущие продажи и задачу будущего сайта. Без длинного предварительного брифа и попытки заставить вас заранее спроектировать сайт за нас.
{здесь вставить CTA}
Обсудить проект с Sadovnikov.digital
Расскажите, что хотите изменить в бизнесе с помощью сайта. Мы разберём вводные и предложим следующий шаг.
[Записаться на интервью]