Чтобы начать разговор о сайте, не обязательно писать технический документ на десятки страниц. Достаточно собрать бизнес-контекст и открытые вопросы. Подробное задание появляется, когда понятны пользователи, сценарии и ограничения — и заказчик с командой одинаково понимают будущий результат.

Коротко

Полезное задание описывает не только страницы и внешний вид, но и действия пользователя, работу с данными и проверяемый результат.

Не путайте бриф и техническое задание

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

На старте нормально не знать, какая система управления нужна или как устроить интеграцию. Лучше честно обозначить вопрос, чем выбрать технологию наугад и сделать её обязательным условием. Подрядчик должен помочь разобраться в вариантах и объяснить последствия выбора.

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

Опишите цель и основные сценарии

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

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

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

Соберите структуру и материалы

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

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

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

Описывайте функции через поведение

Фраза «нужна форма заявки» оставляет много вопросов. Какие поля обязательны? Куда поступает обращение? Что видит посетитель при ошибке? Нужно ли прикладывать файл? Как защититься от повторной отправки? Такие детали влияют на реальную работу сайта.

Пример проверяемого требования

Посетитель указывает телефон или почту и описывает задачу. Без контакта форма показывает понятную ошибку. При успешной доставке обращения получателю посетитель видит подтверждение; при сбое введённые данные сохраняются в форме.

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

Укажите интеграции и ответственность за данные

Перечислите действующие системы: CRM, складской учёт, платёжный сервис, доставка, аналитика. Запишите, какими данными они должны обмениваться и кто со стороны компании может уточнить детали. Если документации или доступа пока нет, отметьте это как зависимость для оценки.

Важно решить, где хранится исходная запись и кто может её изменять. Например, цена управляется в учётной системе, а сайт её получает. Если редактировать цену можно в обоих местах, понадобится дополнительное правило разрешения противоречий.

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

Договоритесь, как проверять готовность

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

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

  • Какую задачу решает сайт и для кого?
  • Что обязательно входит в первый запуск?
  • Какие материалы готовы и кто подготовит остальные?
  • Какие действия и ошибки должен обрабатывать интерфейс?
  • Какие системы подключаем и какие данные передаём?
  • Кто согласует этапы и по каким критериям принимает результат?

С этим списком уже можно идти на первую встречу. Если вы ещё выбираете подрядчика, пригодятся вопросы веб-студии до начала работы.