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