Хороший бриф не обязан содержать готовую структуру, дизайн и техническое задание. Его задача — передать подрядчику контекст, ограничения и критерии решения. Если заказчик заранее рисует все экраны и перечисляет функции без объяснения бизнес-задачи, команда получает много деталей, но мало оснований для проектных решений.
Этот шаблон можно использовать для нового корпоративного сайта, B2B-каталога, интернет-магазина, реконструкции или крупной доработки. Заполняйте только то, что известно. Неизвестное отмечайте как вопрос для исследования.
Чем бриф отличается от технического задания
Документ | На какой вопрос отвечает | Когда нужен
--- | --- | ---
Бриф | зачем нужен проект, кому он служит, какие есть вводные и ограничения | до оценки и проектирования
Концепция | каким должен быть принцип решения | после диагностики и исследования
Прототип | как организованы страницы и сценарии | после согласования структуры
Техническое задание | что именно реализуется и как принимается | перед разработкой или в её начале
План запуска | как переносится контент, проверяются интеграции и контролируется релиз | до выхода новой версии
Бриф не заменяет последующие документы. Он помогает начать проект с общей картины и сравнивать предложения подрядчиков по одной системе координат.
1. Паспорт проекта
Соберите базовые данные:
- название компании и проекта;
- контактные лица и роли;
- текущий сайт и связанные домены;
- формат проекта: новый сайт, реконструкция, редизайн или доработка;
- желаемая дата запуска и причина этой даты;
- ориентиры по бюджету или порядок его согласования;
- кто принимает итоговые решения;
- кто предоставляет контент, данные и доступы;
- какие подрядчики или внутренние команды участвуют.
Вопрос, который стоит задать
Что произойдёт, если сайт не будет запущен к указанной дате? Ответ помогает отделить реальное ограничение от календарного пожелания.
2. Бизнес-задача
Не ограничивайтесь формулировкой «нужен современный сайт».
Опишите:
- какие продукты или услуги находятся в приоритете;
- какую роль сайт играет в продажах;
- где начинается и заканчивается его зона ответственности;
- какие проблемы текущей системы нужно устранить;
- какие решения пользователь должен принимать на сайте;
- какие действия считаются целевыми;
- как сайт связан с маркетингом, продажами, поддержкой и партнёрами;
- какие изменения бизнеса ожидаются в ближайшей перспективе.
Пример хорошей формулировки
> Нужен B2B-каталог, который помогает инженеру подобрать группу оборудования по > применению, сравнить ключевые характеристики и передать менеджеру запрос с > контекстом выбранных позиций. Цены зависят от комплектации и не публикуются.
Здесь понятны аудитория, сценарий, данные и ограничение. Формулировка «разработать красивый каталог» не даёт такой опоры.
3. Аудитории и роли в выборе
Для сложного продукта редко существует один «пользователь».
Заполните таблицу:
Роль | Задача | Что важно увидеть | Что мешает решению | Следующий шаг
--- | --- | --- | --- | ---
Инициатор | найти возможное решение | применимость и варианты | непонятная терминология | сохранить или отправить коллегам
Технический специалист | проверить соответствие | характеристики, документация, ограничения | неполные данные | запросить консультацию
Руководитель | оценить поставщика и риски | опыт, процесс, ответственность | общие обещания | обсудить проект
Закупщик | сравнить условия | состав поставки, сроки, документы | несопоставимые предложения | запросить предложение
Замените пример реальными ролями. Для каждой определите информацию и действие, а не только возраст или должность.
4. Продуктовая и сервисная структура
Опишите, что должно быть представлено на сайте:
- направления бизнеса;
- категории и подкатегории;
- продукты, услуги или решения;
- применения и отрасли;
- регионы и филиалы;
- бренды, серии и модификации;
- сопутствующие услуги;
- документация и материалы;
- связи между сущностями.
Если существует каталог, приложите выгрузку полей. Отметьте обязательные, опциональные и внутренние данные.
Таблица сущностей
Сущность | Пример | Ключевые поля | Источник данных | Частота обновления
--- | --- | --- | --- | ---
Категория | тип оборудования | название, описание, фильтры | CMS | по мере изменений
Товар | модель | характеристики, документы, изображения | 1С/PIM/CMS | регулярно
Услуга | монтаж | состав, условия, этапы | CMS | редко
Проект | внедрение | задача, роль, подтверждённые факты | CMS | после согласования
Не включайте персональные данные и сведения, права на публикацию которых не подтверждены.
5. Пользовательские сценарии
Опишите несколько маршрутов в формате:
> Пользователь приходит с [контекстом], хочет [решение], проверяет [условия], > переходит к [следующему шагу].
Например:
- специалист ищет оборудование по применению;
- открывает страницу решения;
- переходит к подходящим категориям;
- сравнивает характеристики;
- скачивает документацию;
- отправляет запрос с выбранными позициями.
Для каждого сценария укажите альтернативы и точки, где требуется помощь менеджера.
6. Контент и доказательства
Перечислите доступные материалы:
- описания компании, продуктов и услуг;
- технические характеристики;
- фото и схемы;
- сертификаты и инструкции;
- кейсы и отзывы с подтверждёнными правами;
- информация о процессе;
- ответы экспертов;
- юридические документы;
- существующие SEO-материалы.
Отдельно укажите:
- что можно публиковать без ограничений;
- что требует согласования;
- чего ещё нет;
- кто отвечает за подготовку и проверку;
- какие материалы нужно перенести со старого сайта.
Не ставьте подрядчику задачу «написать весь контент» без перечня источников и ответственных. Контент влияет на структуру, сроки и критерии приёмки.
7. SEO и сохранение накопленной видимости
В брифе должны быть:
- доступы к системам аналитики и панелям вебмастеров;
- перечень важных текущих URL;
- данные об органическом спросе, если они доступны;
- регионы продвижения;
- приоритетные продукты и услуги;
- требования к редиректам;
- правила переноса метаданных и контента;
- необходимость сохранить файлы, документы и внешние ссылки;
- ответственный за SEO-проверку до и после запуска.
Если новый сайт заменяет действующий, добавьте план подготовки сайта к SEO. Вопросы миграции нельзя оставлять на день релиза.
8. Интеграции и данные
Для каждой интеграции опишите:
Система | Что передаётся | Направление | Частота | Владелец | Критерий проверки
--- | --- | --- | --- | --- | ---
CRM | обращения и контекст | сайт → CRM | сразу | продажи | тестовая заявка создана корректно
1С/PIM | товары, цены, остатки | система → сайт | по регламенту | IT/каталог | поля и статусы совпадают
Аналитика | события и параметры | сайт → система | сразу | маркетинг | журнал тестов пройден
Телефония | звонки и источник | двусторонне | по возможностям | продажи | тестовый звонок связан
Укажите тестовый контур, ограничения API, документацию и контакт технического специалиста. Не передавайте пароли в самом брифе.
9. Аналитика и критерии измерения
Зафиксируйте:
- основные типы обращений;
- события ключевых сценариев;
- источники и метки;
- передачу данных в CRM;
- правила проверки качества;
- требования к согласию и приватности;
- журнал тестирования перед запуском;
- ограничения атрибуции.
Не просите «настроить все цели». Перечислите конкретные действия и решения, которые должны поддерживать данные.
10. Визуальное направление
Полезнее описать принципы, чем прислать список сайтов «нравится».
Укажите:
- характер бренда;
- допустимые и запрещённые визуальные приёмы;
- фирменные цвета и шрифты;
- требования к фотографии и иллюстрациям;
- доступные бренд-материалы;
- тип контента, который должен быть особенно заметен;
- требования к accessibility;
- примеры с пояснением, что именно в них полезно.
Референс не является макетом. Он помогает обсудить ритм, иерархию и характер, но не даёт права копировать композицию.
11. Технические и организационные ограничения
Проверьте:
- CMS и допустимость её замены;
- хостинг и инфраструктуру;
- требования безопасности;
- браузеры и устройства;
- языковые версии;
- интеграции;
- юридические тексты и согласия;
- процесс согласования;
- доступность экспертов заказчика;
- окна релиза;
- поддержку после запуска.
Чем раньше ограничение известно, тем меньше вероятность переделки.
12. Приёмка и запуск
Согласуйте не абстрактное «всё работает», а проверяемые условия:
- утверждённые страницы и сценарии реализованы;
- контент загружен и проверен ответственными;
- формы и интеграции проходят тестовые сценарии;
- события аналитики зафиксированы в журнале;
- ключевые URL, canonical и редиректы проверены;
- нет критического горизонтального overflow;
- мобильные состояния проверены;
- права и alt-тексты изображений зафиксированы;
- создана резервная копия и план отката;
- назначены ответственные за мониторинг после запуска.
Копируемый шаблон брифа
1. О компании и проекте
- Компания:
- Контактные лица и роли:
- Текущий сайт:
- Формат проекта:
- Желаемая дата запуска и причина:
2. Задача
- Какую бизнес-задачу решает сайт:
- Какие проблемы есть сейчас:
- Какие направления приоритетны:
- Что считается полезным результатом:
3. Аудитории
- Основные роли:
- Их задачи:
- Критерии выбора:
- Барьеры:
- Целевые действия:
4. Структура и данные
- Разделы:
- Продукты/услуги:
- Каталог и фильтры:
- Регионы:
- Источники данных:
5. Контент
- Что готово:
- Что требует подготовки:
- Что переносится:
- Кто отвечает:
- Какие права нужно подтвердить:
6. Интеграции
- CRM:
- Учётная система:
- Аналитика:
- Телефония:
- Другие системы:
7. SEO и миграция
- Приоритетные направления:
- Важные текущие URL:
- Регионы:
- Требования к редиректам:
- Ответственный за SEO:
8. Ограничения и приёмка
- CMS/инфраструктура:
- Сроки:
- Бюджетный порядок:
- Юридические требования:
- Критерии готовности:
- Ответственные за согласование:
Красные флаги заполнения
- В брифе есть только список функций.
- Цель описана как «сделать современно».
- Аудитория сведена к возрасту.
- Нет владельцев контента и данных.
- Интеграции названы, но не описан обмен.
- Дата запуска не связана с бизнес-событием.
- Старые URL и SEO предлагается проверить после релиза.
- Приёмка зависит только от субъективного впечатления.
Связанные материалы
- Гайд: как оценить подрядчика — как
- Чек-лист: аудит сайта и маркетинга —
сравнивать процесс, доказательства и ответственность команд. что проверить перед формированием требований к новому сайту.
Следующий шаг
Заполненный бриф — исходная точка для разговора, а не готовое техническое решение. На старте подрядчик должен проверить вводные, обозначить противоречия и предложить процесс проектирования.