Корпоративный сайт чаще всего начинают «с экранов»: главная, каталог, контакты. Но у маркетинга на руках обычно другой набор — презентации, заметки продаж, прайс-листы, список конкурентов. Готового ТЗ нет, и это нормально: бриф не заменяет техническое задание, он даёт исходные данные для структуры и границы оценки. Неописанные сценарии подрядчик всё равно оценит — просто как предположения. Лучше пометить их как неизвестные заранее.
Аудитория через задачи, а не через должности
Перечень отраслей и «портрет клиента» сам по себе проектированию почти не помогают. Полезнее для каждого приоритетного сегмента зафиксировать вопрос, с которым человек приходит на сайт: сравнить услугу, проверить опыт в отрасли, получить документ, найти сервис, оставить запрос. У одного лица может быть несколько задач, поэтому один «средний клиент» — плохой ориентир для структуры.
Предложение и его границы
В бриф входят названия услуг, состав работ, территория, условия начала сотрудничества и факты, которые можно подтвердить. Отдельно стоит выписать запреты: неустановленные сроки, индивидуальные цены, закрытые проекты, неутверждённые характеристики. Это защищает страницу от текста, который убедительно выглядит, но не проходит согласование.
Доказательства ищут до макетов
Кейсы, сертификаты, фотографии, документы, отзывы и цифры попадают в бриф только с владельцем и правом публикации. У каждого материала желательно указать источник, дату проверки и где его можно использовать. Если доказательства собирают в конце проекта, структура уже может не иметь для них понятного места — и они либо теряются, либо ломают макет.
Сценарий обращения
Бриф фиксирует целевое действие: звонок, короткая форма, запрос расчёта, запись, скачивание документа после контакта. Для формы определяют минимальные поля, сообщения об ошибках, согласие и получателя заявки. Вопрос «какие данные нужны менеджеру» лучше решать вместе с продажами, а не переносить в форму весь опросник по привычке.
Системы и данные
Нужны сведения о CMS, CRM, аналитике, телефонии, личном кабинете, каталогах и источниках контента. Интерфейсы описывать не нужно, но важны владелец системы, способ обмена и ограничения доступа. Тогда интеграции выделяются в отдельную часть оценки, а не прячутся под формулировкой «подключить CRM».
Порядок принятия решений
В брифе указывают владельцев контента, дизайна, юридических формулировок и технических доступов. Плюс ритм согласования: что показывают на прототипе, сколько длится проверка, как оформляют изменение. Без этого даже хороший список вопросов превращается в бесконечный тред комментариев.
Статусы вместо пустых полей
У каждого ответа полезен статус: подтверждено, требует решения или неизвестно. Пустое поле хуже явной неопределённости — на стартовой встрече команда обсуждает конкретные пробелы, а не имитирует готовность.
Частые вопросы
Можно ли заполнить бриф без интервью с продажами? Черновик собрать можно, но сценарий обращения и типовые вопросы стоит подтвердить с теми, кто работает с лидами. Иначе форма опирается только на внутреннее представление маркетинга.
Нужны ли конкуренты? Да, если понятно, что анализируют: структура услуг, способ объяснить условие, формат доказательства или сценарий обращения. Просто список ссылок мало помогает.
Надо ли сразу описывать дизайн? Достаточно брендовых ограничений, примеров по смыслу и требований к доступности. Интерфейс формируется после проверки структуры и сценариев.
Что делать с неизвестными данными? Пометить и назначить владельца ответа. Неизвестность в брифе безопаснее выдуманного требования в ТЗ.
Итог
Бриф готов к оценке не когда заполнена каждая строка, а когда понятны цель, сценарии, ограничения и владельцы незакрытых вопросов. Перед оценкой его проверяют на противоречия: если в одном месте компания хочет короткую заявку, а в другом требует обязательный опросник — это решают до прототипа. Такой документ можно уточнять по ходу проекта: неизвестные данные не маскируются под требования и не становятся случайными допущениями в прототипе или смете.
Top comments (0)