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