Бриф — это не бюрократическая формальность и не документ «для галочки». Это набор ответов, которые до старта работ снимают неопределённость. И чем меньше неопределённости, тем меньше правок, переделок и незапланированных часов в счёте. Хорошо проработанный бриф часто сокращает число итераций в дизайне и разработке в разы, а иногда и сам объём работ. Разберём, какие вопросы стоит задать себе до того, как подрядчик назовёт цифру.
Почему бриф напрямую влияет на бюджет
Любая оценка строится на вводных. Если вводных нет, подрядчик либо закладывает в смету риски (то есть вы платите за неизвестность), либо оценивает «по ощущениям» — и потом пересматривает оценку. Что даёт проработанный бриф:
- Меньше правок. Спорные решения обсуждаются на бумаге, а не в готовом макете.
- Точная оценка. Понятный объём работ считается, а не угадывается.
- Сравнимость предложений. Разные подрядчики считают одно и то же, а не каждый своё.
- Защита от «допов». Всё, что зафиксировано, не превращается в дополнительные счёта по ходу проекта.
Блок 1. Цели и задачи бизнеса
Начинать нужно не с дизайна и не со «структуры сайта», а с вопроса «зачем». Сайт — инструмент, у него должна быть измеримая задача.
Вопросы, на которые нужен ответ
- Какую задачу решает сайт: заявки, продажи, информирование, поддержка клиентов, имидж?
- Как вы поймёте, что проект удался? Какая метрика — заявки, конверсия, звонки, время на ответ?
- Что происходит сейчас: сайта нет, есть устаревший, не хватает функциональности?
- Кто внутри компании принимает финальное решение по проекту?
- Есть ли жёсткие сроки — сезон, запуск продукта, выставка?
Блок 2. Аудитория и сценарии
Даже короткое описание пользователей сильно влияет на решения. B2B-клиент и частный покупатель ведут себя на сайте по-разному.
- Кто ваши ключевые сегменты пользователей?
- С каких устройств они чаще приходят — мобильные, десктоп?
- Какие вопросы должны закрываться на сайте до обращения?
- Какие возражения нужно снять: цена, сроки, доверие, сложность?
- Какие 2–3 сценария самые важные? Опишите их шагами: пришёл → посмотрел → сделал.
Такой «облегчённый CJM» помогает не изобретать лишние разделы и не терять нужные.
Блок 3. Функциональность и контент
Что сайт должен уметь
Перечислите функции честно, а потом разделите их на три группы: обязательно в первой версии, желательно, когда-нибудь. Формы, личный кабинет, оплата, каталог с фильтрами, поиск, блог, мультиязычность, калькулятор — всё это разная стоимость разработки и поддержки.
Откуда возьмётся контент
Контент — самая частая причина срыва сроков. Поэтому в брифе стоит зафиксировать:
- Кто пишет тексты — вы, подрядчик, отдельный копирайтер?
- Есть ли фото, видео, иллюстрации? Нужны ли съёмки?
- Сколько страниц и разделов планируется изначально?
- Нужны ли переводы и на каких языках?
- Кому принадлежат права на материалы?
Блок 4. Дизайн и визуальные ориентиры
Фраза «нравится — не нравится» без объяснения бесполезна. Работает другое: примеры сайтов с комментарием, что именно нравится — структура, подача, цвет, темп.
- Есть ли фирменный стиль, брендбук, логотип в векторе?
- Какие 3–5 сайтов нравятся и почему? Какие не нравятся и почему?
- Есть ли обязательные элементы: цвета, шрифты, тон общения?
Блок 5. Технологии и интеграции
- Есть ли предпочтения по CMS или платформе?
- Нужны ли интеграции: CRM, 1С, ERP, платёжные системы, службы доставки?
- Какая аналитика уже используется и что нужно настроить?
- Есть ли существующий домен, хостинг, легаси-системы?
- Есть ли требования по безопасности или нагрузке?
Интеграции — один из главных источников скрытых сложностей, поэтому о них лучше сказать сразу.
Блок 6. Процесс, сроки и бюджет
- В каком диапазоне вы готовы работать? Хотя бы порядок цифр.
- Какой дедлайн и что будет, если его сдвинуть?
- Кто со стороны заказчика отвечает за согласования и обратную связь?
- В каком формате принимается работа?
- Нужна ли поддержка после запуска и в каком объёме?
Честно обозначенный бюджет — не повод для торга, а способ отсеять заведомо невыполнимые варианты. Профессиональный подрядчик скажет, что реально сделать в этих рамках, а что нет.
Частые ошибки при составлении брифа
- Много слов, мало ответов. Тридцать страниц рассуждений хуже двух страниц конкретики.
- «Сделайте как у конкурента». Без пояснений это готовая почва для бесконечных правок.
- Умолчание о бюджете и сроках. Оценка получится либо завышенной, либо бесполезной.
- Нет ответственного за проект. Решения принимаются коллективно и никогда не принимаются.
- Смешивание брифа и технического задания. Это разные документы и разные этапы.
Бриф и ТЗ — не одно и то же
Бриф отвечает на вопрос «что и зачем нужно». Техническое задание описывает «как именно это будет сделано» — с точными требованиями, структурой и логикой. Часто правильнее сначала составить бриф, а детальное ТЗ разработать уже вместе с подрядчиком, который знает типовые решения и ограничения.
Короткий чеклист
- Задача сайта и метрика успеха — определены.
- Аудитория и ключевые сценарии — описаны.
- Функциональность разделена на обязательную и желательную.
- Известно, кто отвечает за контент и в какие сроки.
- Есть визуальные ориентиры с пояснениями.
- Интеграции, домен, хостинг, аналитика — перечислены.
- Сроки, бюджетный диапазон и ответственный — зафиксированы.
- Понятно, как будет приниматься работа и что будет после запуска.
Бриф не гарантирует, что проект пройдёт идеально. Но он превращает разговор с подрядчиком из переговоров о догадках в обсуждение конкретной задачи. А значит — экономит время, нервы и деньги обеих сторон.

Спасибо за блок про цели — раньше я считала бриф формальностью, пока не запустила интернет-магазин. Мы расписали метрики, сегменты и 3 сценария, и правок в макетах стало заметно меньше. Особенно согласна про контент: у нас фото и описания товаров появились позже, и это сдвинуло сроки.
Вопрос по третьему блоку: если часть функций пока под вопросом, как лучше фиксировать их в брифе — отдельным списком «желательно» или сразу закладывать архитектуру с запасом? Боюсь, что без этого потом придётся переделывать, но и платить за неиспользуемое не хочется.
Я бы не закладывал личный кабинет или сложную интеграцию «на всякий случай»: это раздувает смету и сроки. Лучше вынести спорное в отдельный этап и оценить как опцию, но в архитектуре предусмотреть возможность добавить позже без полной переделки. Если функция нужна для основной метрики, тогда да, в первую версию.