01
Начните с задачи, а не со списка страниц
Запишите, кто придёт на сайт и зачем: покупатель сравнивает товар, клиент проверяет компетенции, партнёр ищет условия сотрудничества. Для каждого посетителя выберите основное действие. Например, для магазина это может быть поиск товара и оформление заказа, а для компании с индивидуальными проектами — изучение похожей работы и обращение. Список страниц появляется из этих сценариев. Если начинать с пожелания «нужен современный сайт», нельзя проверить, решает ли результат вашу задачу. Достаточно одной страницы с описанием бизнеса, аудитории, текущей проблемы и желаемого изменения.
02
Соберите то, что уже есть
Подготовьте перечень услуг или товаров, логотип, фотографии, тексты, действующие адреса страниц и примеры документов, которые получает клиент. Отметьте материалы, на которые у компании есть права, и то, что ещё предстоит создать. Не передавайте пароли в брифе: достаточно перечислить системы и указать, кто выдаёт доступ. Если сайт уже работает, сохраните список важных страниц и функций. Пример чужого сайта полезен с пояснением: нравится понятная навигация, крупные фотографии товара или короткая форма. Это помогает обсуждать решение, не превращая проект в копирование чужого бренда.
03
Опишите границы первой версии
Разделите пожелания на обязательные для запуска и возможные позже. Для интернет-магазина отдельно обсудите каталог, наличие, доставку, оплату и связь с учётной системой. Для сайта услуг — структуру предложений, кейсы, редактирование контента и путь обращения. Укажите ограничения: когда должны быть готовы материалы, какие системы нельзя менять, кто согласует решения. Неизвестный бюджет или срок лучше так и обозначить, а не подставлять случайную цифру. Стоимость и план можно обсуждать после уточнения состава работ; один список экранов ещё не описывает серверную логику и состояния ошибок.
04
Согласуйте, как будете принимать работу
Замените фразу «должно быть удобно» наблюдаемыми проверками. Например: посетитель на телефоне находит нужный товар; редактор меняет цену в пределах своей роли; при ошибке отправки человек видит понятное сообщение. Зафиксируйте, какие устройства и сценарии проверяются, кто предоставляет контент и кто принимает результат. Отдельно перечислите то, что передаётся после запуска: исходники, доступы, инструкции и договорённые материалы дизайна. Такой бриф не заменяет последующее техническое задание, но даёт общую основу для оценки. Перед обсуждением разработки проверьте, что каждый обязательный пункт можно объяснить через действие пользователя или рабочую задачу вашей команды.