Когда бриф на редизайн — подходящий документ
Бриф на редизайн — это не универсальная форма для сбора вводных. Он нужен для сайта, который уже работает в чем-то хорошо, но в чем-то даёт сбои, и в брифе нужно описывать изменения, а не просто желания. Если команда переделывает корпоративный сайт на 40 страниц, лендинг или продуктовый портал, бриф должен объяснить, что именно нужно изменить, а что оставить как есть.
Это важно, потому что редизайн начинается с уже существующей реальности. Уже есть карта сайта, старые тексты, код отслеживания, формы и CMS со своими привычками. Хороший бриф показывает дизайнеру или агентству, где болит, какие части устойчивы, а какие опасно трогать без плана.
Думайте об этом как о документе по управлению изменениями. Звучит сухо, но зато помогает всем оставаться честными. Фрилансеру проще точнее оценить работу, внутренней команде — не гадать, а клиенту — перестать относиться к каждой старой странице как к чистому листу.
Если вы ищете, как пошагово составить бриф для редизайна сайта, начните с решения, что бриф нужен для трансформации, а не для исследования с нуля. Именно это решение меняет вопросы, которые вы задаёте, и детали, которые собираете.
Проведите аудит текущего сайта, прежде чем что-либо писать
Начните с действующего сайта. Не со скриншотов прошлого квартала. Не с воспоминаний о «проблеме на главной». Откройте текущие страницы и перечислите, что есть, что сломано и что никто не должен забыть во время редизайна.
Сделайте простой аудит с цифрами. Подсчитайте страницы, которые останутся, страницы, которые изменятся, и страницы, которые будут удалены. Отметьте страницы с хорошим трафиком, формы с потерями, разделы, которые путают пользователей, и контент, который устарел на год или больше.
Технические ограничения тоже важны. Если сайт работает на устаревшей CMS, нестандартном сценарии оформления заказа или хрупкой интеграции, бриф должен упомянуть это до того, как кто-то начнёт рисовать новый макет. Редизайн, который игнорирует текущую систему, часто превращается во второй проект: в тушение пожара.
Добавьте конкретные проблемы пользователей. Например: обращения в поддержку говорят о проблемах с поиском на мобильных; отдел продаж сообщает, что страница с ценами вызывает повторные звонки; редакторы не могут обновлять FAQ без помощи разработчика. Такие детали лучше расплывчатых формулировок вроде «сайтом неудобно пользоваться».
Если у вас уже есть внутренняя документация, дайте на неё ссылку. Команда, которая проводит проверку аудит сайта перед редизайном или настраивает аналитику, уже может знать, где находятся текущие риски, и это сэкономит часы позже.
Определите границы редизайна и то, что не входит в задачи
Брифы на редизайн проваливаются, когда границы проекта остаются размытыми. Запишите, что входит в объём работ, простыми словами, а затем отдельно — что не входит. Второй список важен не меньше первого, потому что он не даёт команде расползтись в дополнительные шаблоны, функции и круги согласований.
Будьте конкретны в обозначении границ. Если в проект входят главная, страницы продуктов и контактный сценарий, так и скажите. Если архив блога, языковые версии или личный кабинет не входят в этот этап, тоже напишите об этом. Редизайн может затронуть 12 шаблонов, не затрагивая всю систему целиком.
То, что не входит в задачи, — это не признак лени. Это защита. Если доработка SEO-контента вне рамок проекта, укажите это. Если новые фотографии не предусмотрены, напишите прямо. Если редизайн должен оставить прежнего провайдера оплаты, зафиксируйте это, чтобы никто не предложил замену на третьей неделе.
Полезная строка в брифе на редизайн: «Сохранить текущий процесс оплаты без изменений». Ещё одна: «В этом этапе не менять клиентскую панель». Просто. Понятно. Трудно истолковать неверно.
Опишите бизнес-контекст, бренд и пользователей
Бриф на редизайн должен давать контекст, но не превращаться в манифест бренда. Кратко изложите бизнес-цель в одном блоке: рост выручки, качество лидов, нагрузка на поддержку, потребность в найме или выход на новый рынок. Если редизайн связан со слиянием, ребрендингом или переходом от B2B к B2B2C, назовите это.
Брендовый контекст должен включать именно те изменения, которые произошли. Возможно, компания теперь больше ориентируется на корпоративный сегмент. Возможно, тон стал более экспертным, а не игривым. Возможно, визуальная система должна выглядеть спокойнее, потому что старый дизайн казался слишком рекламным. Это полезные детали. «Современно» — нет.
Пользовательский контекст должен отражать реальные изменения, а не предположения. Если аудитория стала больше пользоваться мобильными устройствами, это влияет на шаблоны и навигацию. Если постоянным клиентам теперь нужен более быстрый доступ к аккаунту, чем новым посетителям — к обучающему контенту, это должно быть видно на главной, в меню и в личном кабинете.
Здесь одной фразы может быть достаточно: «Редизайн должен поддерживать три аудитории — новых лидов, текущих клиентов и партнёров — не заставляя главную страницу тянуть на себе всё». Это даёт команде задачу, которую можно решить, а не просто лозунг.
Для крупного проекта может помочь ссылка на пример структуры корпоративного сайта или на сайт одного из бизнес-направлений, чтобы команда поняла, как организация уже себя представляет.
Укажите требования к страницам и структуре сайта
Бриф на редизайн не должен ограничиваться фразой «новая навигация». В нём нужно назвать структуру сайта, основные шаблоны и страницы, которым требуется особое внимание. Начните хотя бы с чернового списка карты сайта. Затем выделите приоритетные страницы в первую очередь.
Например, сайту на 20 страниц может понадобиться новая главная, два шаблона услуг, макет кейса, хаб материалов и страница контактов с другой формой. Продуктовой компании могут понадобиться страница цен, страница сравнения и сценарий регистрации на пробный период. Издателю — фильтры архива и шаблоны статей с более продуманными путями чтения.
Скажите команде, какие типы страниц повторяются, а какие являются исключениями. Если шаблон блога может выдержать 500 статей, а шаблон кейса требует индивидуального сторителлинга, напишите это. Если в навигации должны быть только 6 верхнеуровневых разделов, тоже укажите это. Здесь помогают цифры.
Это также место для изменений в иерархии контента. На странице может остаться та же информация, но понадобиться другой порядок: сначала доказательства, потом преимущества, потом процесс, FAQ — в конце. Такая логика не даёт редизайну превратиться в косметическую замену при той же старой структуре внутри.
Некоторые команды строят это на основе платформы аналитики и мониторинга сайта или внутренней карты контента, чтобы видеть, какие страницы уже держат основную нагрузку, а какие используются слабо.
Укажите миграцию контента, согласования и зоны ответственности
Именно на миграции контента редизайны чаще всего становятся хаотичными. В брифе нужно указать, что переносится без изменений, что переписывается, что архивируется и что создаётся с нуля. Если есть 86 старых статей, а мигрировать нужно только 20, это число должно быть указано чётко.
Зоны ответственности не менее важны. Кто пишет новые тексты? Кто проверяет юридические формулировки? Кто утверждает заголовок главной страницы? Если одну страницу согласуют 4 человека, это сразу отразится на сроках. В брифе нужно назвать ответственного за каждый этап, а не только того, кто ставит финальное «ок».
Визуальные согласования требуют той же внимательности. Руководитель маркетинга может утверждать тон, руководитель продукта — точность описания функций, а основатель — захотеть финально посмотреть на общий месседж. Это нормально, если в брифе указан порядок. Иначе дизайнер будет переделывать одну и ту же страницу трижды под три разных мнения.
Владение материалами — это практический вопрос. Укажите, кто предоставляет изображения, иконки, диаграммы, отзывы и видео. Если редизайн зависит от 12 скриншотов продукта, а их ещё нет, это риск для сроков, а не мелочь.
Перечислите технические требования, требования к доступности и интеграциям
Технические примечания должны быть в брифе, даже если дизайнер не пишет весь код. Укажите CMS, хостинг, инструменты форм, аналитику и любые системы, с которыми редизайн должен интегрироваться. Если сайт использует собственную синхронизацию с CRM или платёжный инструмент, редизайн не может это игнорировать.
Требования к доступности должны быть конкретными. Упомяните навигацию с клавиатуры, контрастность цветов, подписи к полям, состояния фокуса, субтитры и совместимость со скринридерами — там, где это уместно. Если у компании есть официальный стандарт, сослитесь на него. Если нет, попросите команду следовать признанным рекомендациям по доступности и отмечать страницы, которым нужен особый контроль.
SEO тоже относится сюда, и не как второстепенная задача. В брифе нужно попросить настроить редиректы, сохранить метаданные там, где это нужно, и продумать страницы, которые переименовываются или удаляются. Одна плохая карта редиректов может стоить трафика неделями.
Если у вашей команды свой стек или закрытая инфраструктура, укажите это. Редизайн для инфраструктуры частной сети сильно отличается от публичного сайта-визитки, и бриф должен отразить это ограничение ещё до того, как начнут множиться идеи дизайна.
Требования к тестированию тоже стоит зафиксировать. Укажите, нужно ли проверять сайт в 3 браузерах или в 5, фиксированы ли мобильные точки перелома или они гибкие, и нужны ли на финальной передаче документированные заметки по QA. Эти детали экономят время на неделе запуска.
Добавьте критерии принятия решений и вопросы для следующего шага
Бриф на редизайн не должен заканчиваться фразой «предложите, пожалуйста, идеи». Он должен попросить команду ответить на конкретные вопросы. Какой концептуальный подход лучше всего подходит под текущую проблему сайта? Какие риски они видят? Что требует дополнительного исследования? Какие страницы стоит делать в первую очередь, а какие могут подождать?
Если команда работает с оценками в диапазонах, попросите их именно в таком формате. Попросите указать зависимости. Спросите, какие допущения имеют наибольшее значение. Сильный бриф приглашает агентство или внутреннего дизайнера ответить недостающими частями, а не только мудбордом и красивым PDF.
Этот раздел может также задать критерии принятия решений. Например: приоритетом должна быть ясность, а не визуальная новизна; или конверсия на странице контактов важнее декоративности главной. Если в брифе сказано, что редизайн не должен замедлять загрузку страницы больше чем на заданный предел, команда понимает, какой компромисс важнее всего. Цифры удерживают обсуждение в реальности.
Хорошие вопросы для следующего шага: какие шаблоны нужно тестировать в прототипе? Какие области контента нуждаются в воркшопе по текстам? Что можно повторно использовать из текущей дизайн-системы? Где самый большой риск на запуске? Эти вопросы помогают команде перейти от брифа к плану, не делая вид, что все неизвестные уже решены.
Некоторые команды также просят сослаться на выбор CMS, если платформа ещё не выбрана, потому что ограничения платформы могут повлиять на макеты, процесс редактирования и даже на сам объём редизайна.
И если бриф будет влиять на поддержку после запуска, добавьте одну строку о том, что происходит после выхода в продакшн. Редизайн, который меняет URL, формы или интеграции, часто требует поддержки сайта после запуска в течение нескольких недель, а не передачи «в один день».
Перед отправкой перечитайте бриф так, будто команда видит сайт впервые. Если не хватает количества страниц, если неясно, что не входит в задачи, если не указан ответственный за согласование — исправьте это сейчас. В этом и есть разница между брифом на редизайн, который двигает работу вперёд, и брифом, который просто запускает ещё одно совещание.
