Содержание 9 разделов ↘
Результат: рабочая структура технического задания на сайт. По ней можно обсудить проект с разработчиком, сравнить предложения и проверить результат без бесконечных споров о том, что подразумевалось «по умолчанию».
Гайд подходит для корпоративного сайта, каталога, интернет-магазина или посадочной страницы. Он не заменяет техническую спецификацию интеграций и архитектуру данных: эти части должны быть подготовлены профильными специалистами и согласованы отдельно.
Шаг 1. Опишите задачу бизнеса одной понятной фразой
Начните с того, что должно измениться после запуска: больше квалифицированных запросов на оптовую закупку, удобный подбор товара, запись в определённый филиал, снижение нагрузки на менеджеров или развитие продаж в новых регионах. Запишите текущую проблему и то, как измерите улучшение. «Современный адаптивный сайт» — свойство интерфейса, а не причина строить новый.
Слабый: «Нужен корпоративный сайт на 20 страниц, стильный, с анимацией и формой». Полезный: «Производитель стройматериалов хочет находить новых дилеров. Сейчас сайт смешивает розницу и оптовые условия, а запросы с регионов не показывают объём закупки. Нужны каталог, условия партнёрства, страница регионов, форма B2B-запроса и аналитика первой закупки».
Шаг 2. Разделите аудитории и их задачи
Не ограничивайтесь записью «целевые клиенты — мужчины и женщины 25–55 лет». Для каждого сценария укажите роль человека, задачу, что он уже знает, какой вопрос должен решить до заявки и какое действие является успехом. Для опта — закупщик и повторный заказ; для услуги — руководитель и обсуждение задачи; для e-commerce — покупатель и завершённый заказ.
| Аудитория | Что должна сделать на сайте | Какие данные нужны |
|---|---|---|
| Новый оптовый клиент | Найти ассортимент и запросить коммерческие условия | Минимальная партия, регионы, форма B2B |
| Действующий дилер | Уточнить наличие и повторить закупку | Каталог, личный кабинет или CRM-процесс |
| Частный покупатель | Выбрать модель, цену и доставку | Характеристики, остатки, оплата, возврат |
Шаг 3. Составьте структуру сайта по задачам пользователей
Для каждой важной страницы укажите основную задачу пользователя и поисковое намерение, которому она должна отвечать. Укажите, кто её откроет, что должен узнать и куда перейти. В структуре могут быть страницы услуг, категорий, отраслей, сравнений, справочных материалов и контактов. Не создавайте сотни близких SEO-страниц по комбинациям услуги и города без самостоятельной пользы.
Если есть действующий сайт, приложите список текущих URL и статус каждого: оставить, переработать, объединить, перенести или удалить. Если меняются адреса, план миграции и редиректов — отдельное обязательное приложение. Новый красивый дизайн не оправдывает потерю полезного контента и ссылок.
Шаг 4. Опишите каждый важный пользовательский путь
→
→
→
Проверьте хотя бы три пути: первичный посетитель из поиска, человек, сравнивающий варианты, и возвращающийся клиент. Зафиксируйте, что произойдёт, если товара нет в наличии, форма выдаст ошибку или пропадёт соединение, длинном названии компании или повторной отправке. Это предотвратит множество исправлений уже после запуска.
Шаг 5. Разделите визуальный дизайн и данные
Укажите референсы по типографике, ритму, карточкам, графике и взаимодействию. Но не требуйте рисовать каждый контентный элемент отдельно: нужна дизайн-система, в которой новые страницы собираются из контролируемых компонентов. В предусмотренной проектом системе редактирования контента сотрудник должен менять текст, изображения и метаданные, не нарушая верстку и работу страниц.
Сразу согласуйте мобильные состояния, отступы, размеры шрифтов и управление без наведения курсора. Для длинных схем нужна последовательная мобильная версия, а не уменьшение десктопной картинки до нечитаемого размера. Зафиксируйте требования к контрасту, фокусу клавиатуры и отключению анимаций.
Шаг 6. Отдельно опишите интеграции
Для форм укажите обязательные поля, валидацию, согласия, защиту от спама, успешную отправку, куда попадает обращение и кто отвечает за уведомление. Для CRM — справочники, передаваемые поля, статус сделки и обработку ошибок. Для магазина — каталог, цена, остатки, корзина, оплата, отмена, возврат. Не просите «подключить CRM» без списка событий и ответственных систем.
| Интеграция | Что передаём | Как проверяем |
|---|---|---|
| Заявка → CRM | Тема, контакты, страница и источник при разрешённом сборе | Тестовая заявка с ID и ответственным |
| Заказ → аналитика | Согласованное событие покупки, сумма, ID заказа | Сверка с заказом и отсутствие дубля |
| Каталог → сайт | Наименование, SKU, цена, наличие | Смена остатка в учётной системе |
| Отправка заявки → уведомление | Статус доставки без лишних персональных данных | Контроль ошибок и повторной отправки |
Шаг 7. Зафиксируйте поисковые и технические требования
Укажите индексацию, единые URL, title и description, H1, canonical, schema при уместности, хлебные крошки, карты сайта, robots/noindex для служебных разделов, SSR основного контента и внутренние ссылки. Важно, чтобы разработчик проверял результат в HTML и браузере, а не только в исходном Figma-макете.
Для скорости определите проверяемые показатели и условия тестирования. Одно числовое требование без устройства, сети и реального контента может создать иллюзию контроля. Изображения должны быть адаптивными, тяжёлые блоки — загружаться по необходимости, а анимация — не мешать взаимодействию.
Шаг 8. Пропишите приёмку по сценариям
Фраза «работает как в дизайне» не заменяет тесты. Подготовьте матрицу: функциональность, устройство, действие пользователя, ожидаемый результат, кто проверяет и что считается блокирующей ошибкой. Для публичного сайта проверяйте URL со статусом 200, метаданные и доступный текст; для форм — реальную доставку в CRM; для каталога — цены и остатки; для меню — работу на всех типах страниц.
Если страница красивая в макете, но форма не передаёт контакты, мобильная версия обрезает блоки, внутренние ссылки ведут на 404 или старые URL не перенаправлены, работа не завершена. Эти условия должны быть известны до начала разработки, а не появляться при споре об оплате.
Шаблон разделов технического задания
| Раздел ТЗ | Что приложить |
|---|---|
| Бизнес-цели | Текущая проблема и результат |
| Аудитории и сценарии | Роли, задачи, пути покупки |
| Карта страниц | URL, назначение, контент-владелец |
| Дизайн-система | Типографика, компоненты, мобильные состояния |
| CMS и данные | Типы контента, поля, роли редакторов |
| Интеграции | Схема событий и тестовые данные |
| SEO и перенос | Карта адресов, метаданные, редиректы |
| QA и выпуск | Сценарии тестов, критерии приёмки |
В завершение проверьте с потенциальным подрядчиком, какие вопросы он задаёт о продукте, пользователях, контенте, интеграциях и SEO. Если оценка строится только по числу страниц, команда ещё не понимает объём работы. Хорошее ТЗ даёт право честно сравнить предложения, но оставляет исполнителю пространство для профессиональных технических решений.
