Бриф на разработку сайта: что заполнить перед оценкой проекта

Зачем нужен бриф и чем он отличается от технического задания

Бриф помогает заказчику и разработчику одинаково понять задачу до оценки. В нём фиксируют бизнес-цель, аудиторию, важные сценарии, материалы и ограничения. Этого достаточно, чтобы определить подходящий формат сайта, границы первой версии и вопросы, которые действительно влияют на стоимость.

Техническое задание появляется позже и описывает согласованное решение: страницы, состояния интерфейса, функции, интеграции и критерии приёмки. Не нужно превращать первый разговор в документ на десятки страниц. Полезный бриф отделяет обязательное от желаемого и не заставляет заказчика заранее проектировать сайт вместо команды.

• Бриф отвечает, зачем нужен сайт и что должен сделать посетитель.
• Прототип показывает структуру и путь пользователя.
• Техническое задание фиксирует согласованную реализацию и проверку результата.

Начните с измеримой задачи сайта

Формулировка «нужен современный сайт» не объясняет, что считать результатом. Сначала выберите одно основное действие: запросить расчёт, записаться, позвонить, получить коммерческое предложение, оформить заказ или начать работу в личном кабинете. Остальные действия можно оставить вспомогательными.

Укажите, откуда ожидается трафик: поиск, Яндекс Директ, рекомендации, рассылка или офлайн-материалы. Посетители из разных каналов приходят с разным уровнем готовности. Страница под рекламный запрос обычно короче и конкретнее, а сайт для органического поиска требует самостоятельных страниц услуг и содержательной структуры.

• Главное целевое действие и подтверждение его успешного выполнения.
• Источники трафика на старте и после запуска.
• Кто будет обрабатывать обращения и в какой срок.
• Какие показатели доступны без обещания гарантированных продаж.

Опишите аудиторию через реальные ситуации выбора

Вместо общего портрета «мужчины и женщины 25–55 лет» перечислите ситуации, после которых человек начинает искать решение. Например: нужно запустить рекламу новой услуги, объединить два сайта после ребрендинга, перестать принимать заказы вручную или показать каталог дилерам.

Для каждой ситуации полезно записать проблему, ожидаемый результат, основные сомнения и данные, необходимые до покупки. Такая фактура помогает сформулировать первый экран, порядок блоков и вопросы формы без выдуманных преимуществ.

Зафиксируйте состав первой версии

Первая версия должна решать главную задачу без функций «на будущее», которые задерживают запуск. Разделите требования на обязательные, желательные и отложенные. Если функция влияет на оплату, учёт, персональные данные или внешнюю систему, её нужно назвать сразу: такие зависимости меняют архитектуру и проверку проекта.

Для обычного сайта услуг достаточно перечислить страницы и смысловые блоки. Для каталога или сервиса дополнительно описывают сущности и действия: товар, фильтр, заказ, пользователь, роль, документ, уведомление. Не требуется придумывать названия полей — важно передать логику процесса.

• Страницы и разделы, необходимые к первому запуску.
• Формы, калькуляторы, поиск, фильтры и личные кабинеты.
• Интеграции с CRM, оплатой, 1С, складом или мессенджерами.
• Роли пользователей и действия, требующие авторизации.
• Что осознанно переносится во второй этап.

Соберите материалы и отметьте их готовность

Оценка зависит не только от количества страниц, но и от готовности содержания. Отдельно отметьте, что уже есть: логотип, фирменные цвета, тексты, фотографии, карточки товаров, документы, домен и доступы. Если материалов нет, нужно заранее определить, кто отвечает за интервью, копирайтинг, съёмку или подбор лицензированных изображений.

Не отправляйте в брифе пароли, базы клиентов и персональные данные. Для оценки достаточно назвать систему и ожидаемый сценарий. Доступы передают только по согласованному защищённому каналу, когда начинается соответствующий этап.

Укажите требования к поиску, рекламе и аналитике

Если у действующего сайта уже есть органический трафик, приложите список важных URL и укажите, планируется ли смена структуры или домена. При редизайне нужны карта соответствий, постоянные редиректы, перенос метаданных и проверка canonical, robots.txt и sitemap. Нельзя обещать неизменные позиции, но риск можно контролировать техническим планом.

Для рекламы перечислите приоритетные услуги, регионы и целевое действие. До запуска проверяют Метрику, цель подтверждённой отправки, UTM-метки и передачу страницы обращения менеджеру. Событие клика по кнопке не заменяет подтверждённую заявку.

• Счётчики аналитики и доступные панели вебмастеров.
• Канонические URL и страницы, которые нельзя потерять.
• Цели: отправка формы, звонок, заказ или другое бизнес-действие.
• Правила хранения рекламных меток с учётом согласия пользователя.

Опишите сроки через зависимости, а не желаемую дату

Дата запуска зависит от объёма первой версии, готовности материалов, скорости согласований и внешних интеграций. В брифе укажите обязательную дату только если она связана с событием, рекламной кампанией или договорным обязательством. Рядом отметьте, какие материалы можно предоставить к старту.

Полезнее согласовать короткие контрольные точки: структура, прототип, визуальное направление, рабочая версия, контент, интеграции и публикация. Тогда задержка на одном этапе видна до того, как она сдвинет весь проект.

Заранее определите, как принимается работа

Критерии приёмки защищают обе стороны от бесконечного «сделайте современнее». Для каждого этапа указывают проверяемый результат: согласованная структура, адаптация для заданных экранов, работа формы, корректная цель аналитики, загрузка страниц и передача доступов.

Визуальные предпочтения лучше показывать примерами с пояснением, что именно нравится: плотность, типографика, подача кейсов или характер анимации. Копировать чужой сайт не нужно — примеры помогают обсудить направление, а не заменить проектирование.

• Список поддерживаемых устройств и браузеров.
• Проверяемые сценарии формы, оплаты и интеграций.
• Ответственный за согласование со стороны заказчика.
• Порядок передачи домена, кода, материалов и административных доступов.

Короткий шаблон брифа для отправки подрядчику

Для первого расчёта можно отправить ответы обычным письмом или сообщением. Необязательно оформлять презентацию. Чем честнее указаны неизвестные и ограничения, тем меньше вероятность, что важная работа появится в смете уже после старта.

• Компания, услуга и ссылка на действующий сайт, если он есть.
• Главная задача сайта и целевое действие посетителя.
• Три–пять ситуаций, в которых клиент начинает искать решение.
• Обязательные страницы, функции и интеграции первой версии.
• Готовые материалы и то, что требуется подготовить.
• Источники трафика, регионы, аналитика и важные текущие URL.
• Желаемый срок, причина даты и доступность команды для согласований.
• Примерный бюджет или границы, в которых нужно выбрать решение.