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

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

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

1. Сначала напишите, ради чего вообще затеян редизайн

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

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

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

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

2. Разделите вид, текст и поведение на разные списки

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

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

С поведением та же история. Фраза «оставить как сейчас» звучит удобно, но без перечня сценариев она почти бесполезна. Нужно назвать, какие формы, корзины, личные кабинеты, письма или маршруты заявок должны пережить визуальное обновление без потерь. Иначе работу примут не по макету, а по тому, что внезапно перестало работать.

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

3. Назовите страницы в работе и страницы вне этой недели

Фраза «обновляем весь сайт» почти никогда не помогает стартовать нормально. У неё нет границы, а значит нет и понятной первой недели. Гораздо полезнее перечислить конкретные адреса, которые меняются в этой фазе, а затем отдельно назвать те, которые трогать не нужно: блог, вход, старые URL кампаний, страницы с активным рекламным трафиком, служебные шаблоны. Именно список исключений часто спасает проект от лишней перестройки.

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

4. Зафиксируйте первую неделю так, чтобы её можно было пересказать с листа

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

Проверки должны описывать действия. Открыть рекламный URL на телефоне. Увидеть предложение и город без долгой прокрутки. Отправить одну тестовую заявку. Убедиться, что на сайте появилось сообщение благодарности и что эта же заявка попала туда, где её реально видит отдел продаж. Изменить одну фразу, которую клиент хочет контролировать сам. Подтвердить, что страница вне объёма осталась прежней. Формулы вроде «выглядит дороже» для такого списка не подходят.

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

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

5. Назовите риски, из-за которых дата перестаёт что-либо значить

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

Когда изменения можно проверять только на живом сайте, это нужно назвать до обещания понедельника. Исправления прямо на боевой версии — не мелочь, а отдельный риск для кампании, особенно если страница уже принимает трафик. Отдельное место для проверки — часть работы, а не лишняя формальность; об этом есть отдельный текст.

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

6. Сначала примите зафиксированный кусок, потом расширяйте границу

Когда первая часть готова, проверять её стоит по тому же списку, который был записан на старте. Лучше делать это на копии сайта и, если возможно, вместе с клиентом. Начинать полезно не со вкуса, а с маршрута: открывается ли страница, читается ли предложение, доходит ли заявка, остались ли целыми страницы вне объёма. Замечания по визуальному ощущению, которых нет в списке, разумнее переносить в следующую фазу, а не превращать их в бесконечную причину не закрывать текущую.

Если какая-то проверка не пройдена, нужно назвать конкретную строку. Общая реплика вроде «что-то не так» не даёт команде следующего шага. Если же во время приёмки клиент добавляет ещё одну страницу, её надо либо оформить новой строкой с новой датой, либо отложить. Молчаливое расширение границы почти всегда превращает первую неделю в третью с тем же счётом.

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

Когда лучше позвать разработчика ещё до обещания даты

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

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