Техническое задание на разработку сайта: структура и чек-лист
Практическое руководство по подготовке ТЗ на сайт: от бизнес-цели и сценариев пользователей до требований к страницам, интеграциям, качеству и приёмке.
Содержание статьи
Основа проекта
Хорошее ТЗ объясняет результат, а не перечисляет технологии
Техническое задание на разработку сайта — это единое описание целей, аудитории, страниц, пользовательских сценариев, функций, данных, интеграций и условий, по которым работа считается выполненной. Оно связывает ожидания бизнеса с решениями дизайнера и разработчика.
ТЗ не обязано быть огромным документом. Для небольшого лендинга оно может занимать несколько структурированных страниц. Для интернет-магазина или веб-приложения потребуется описание каталога, ролей, состояний заказа, интеграций и исключений. Масштаб разный, но принцип один: каждое важное ожидание должно стать понятным и проверяемым.
Что собрать до написания технического задания
Начинать с перечня экранов рано. Сначала нужно понять контекст проекта. Иначе сайт получится аккуратным, но не связанным с реальной работой компании.
Цель и измеримый результат
Какую проблему решает сайт: объясняет сложный продукт, собирает обращения, принимает заказы, разгружает менеджеров или объединяет информацию.
Аудитория и её ситуации
Кто приходит, откуда, с каким вопросом, на каком устройстве и что должен понять до целевого действия.
Контент и ответственные
Какие тексты, фотографии, документы и данные уже есть, кто их готовит, проверяет и обновляет после запуска.
Системы и ограничения
CRM, учётная система, платёжный сервис, телефония, домен, хостинг, требования безопасности и внутренние правила компании.
Полезно отдельно собрать проблемы текущего процесса. Например: менеджеры вручную переносят заявки, посетители не находят документы, цены обновляются в нескольких местах, а мобильная версия теряет часть обращений. Такие наблюдения превращаются в осмысленные требования, а не в пожелания «сделать современно».
Связь решений
От бизнес-цели — к критерию приёмки
Сильное ТЗ сохраняет причинно-следственную цепочку. Сначала формулируется задача бизнеса, затем действие пользователя, нужная для него страница, функция и способ проверки.
Сократить потери обращений
Посетитель отправляет запрос
Услуга или контактная форма
Валидация и передача в CRM
Заявка и источник видны менеджеру
Эта логика защищает проект от случайных функций. Если для элемента нельзя объяснить цель, пользовательское действие и критерий готовности, возможно, его не нужно включать в первую версию.
Структура сайта, страницы и контент
Карта сайта должна отражать путь посетителя, а не внутреннюю структуру компании. Для каждой страницы укажите её задачу, аудиторию, основное действие и источник контента.
| Что описать | Контрольный вопрос | Пример |
|---|---|---|
| Назначение страницы | Что посетитель должен понять? | Увидеть компетенции и формат работы компании |
| Целевое действие | Что он делает дальше? | Открывает кейс, отправляет задачу или звонит |
| Блоки | Какие вопросы закрывает страница? | Проблема, решение, процесс, доказательства, форма |
| Контент | Кто и в каком формате передаёт данные? | Тексты в документе, изображения WebP, таблица услуг |
| Состояния | Что видно при отсутствии или ошибке данных? | Пустой результат поиска, ошибка формы, загрузка |
Для корпоративного сайта дополнительно полезно описать типы материалов: услуги, кейсы, сотрудники, документы, вакансии и статьи. Укажите обязательные поля, связи между сущностями и кто сможет редактировать их после запуска.
Функциональные требования: формы, роли и интеграции
Формулировка «подключить CRM» недостаточна. Нужно указать, какие данные передаются, в какой момент, куда именно, как определяется источник обращения и что происходит при ошибке.
Входные данные + действие пользователя или системы + ожидаемый результат + исключения + способ проверки
Что уточнить для каждой функции
- кто может использовать функцию и нужна ли авторизация;
- какие поля обязательны, какие форматы допустимы и как показываются ошибки;
- где хранятся данные и кому отправляется уведомление;
- что делает система при недоступности внешнего сервиса;
- какие действия записываются в журнал и доступны для аналитики;
- кто предоставляет доступы, документацию API и тестовую среду.
Если вы ещё выбираете между ботом, Mini App и самостоятельным сервисом, сначала определите сценарий по нашей матрице цифровых форматов, а уже затем фиксируйте ограничения выбранной платформы в ТЗ.
Как описать дизайн и интерфейс без фразы «сделать красиво»
ТЗ не должно диктовать дизайнеру каждый отступ, но обязано задавать границы: фирменный стиль, приоритеты, устройства, обязательные элементы и состояния интерфейса.
Визуальная система
Логотип, палитра, шрифты, радиусы, характер графики, допустимые и запрещённые приёмы.
Адаптивность
Поведение меню, таблиц, карточек, форм и сложных элементов на телефоне, планшете и широком экране.
Состояния
Наведение, фокус, загрузка, пустой список, успешная отправка, ошибка, недоступная кнопка и длинный контент.
Референсы с пояснением
Не просто ссылки, а конкретика: полезна навигация, композиция первого экрана или способ подачи каталога.
Прототип особенно полезен для страниц со сложным сценарием. Он позволяет проверить порядок действий до визуальной полировки и разработки. Но правила расчётов, доступов и обмена данными всё равно фиксируются текстом.
Поисковая готовность
SEO-требования нужно заложить до разработки
Поисковая оптимизация — не отдельная доработка после запуска. Архитектура страниц, адреса, контент и технические сигналы связаны между собой, поэтому их лучше согласовать в ТЗ.
Понятные URL, правила для фильтров, canonical, redirects, sitemap.xml и robots.txt.
Уникальные title, description и H1, корректная иерархия заголовков, хлебные крошки.
Ответ на намерение пользователя, авторство, даты обновления, внутренние ссылки и понятные подписи изображений.
Серверный HTML для важных страниц, коды ответов, отсутствие битых ссылок и структурированные данные там, где они уместны.
Не стоит задавать разработчику «процент ключевых слов». Текст должен помогать человеку и естественно раскрывать тему. Полезнее определить поисковые намерения, типы посадочных страниц и правила уникальности контента.
Мобильная версия, скорость, доступность и безопасность
Нефункциональные требования часто вспоминают в конце, хотя именно они определяют, насколько сайтом удобно пользоваться в реальных условиях.
Приоритетные сценарии проходят одной рукой, элементы не перекрываются, формы подходят для нужного типа ввода.
Зафиксированы способ измерения, типовые страницы, условия сети и бюджет на изображения, скрипты и шрифты.
Клавиатурная навигация, видимый фокус, подписи полей, alt-тексты, достаточный контраст и понятные ошибки.
HTTPS, минимизация собираемых данных, защита форм, роли доступа, хранение секретов и резервное копирование.
Список поддерживаемых браузеров и устройств, а также порядок обработки особенностей старых версий.
Поведение при сбое интеграции, повторная отправка, журналирование и ответственные за восстановление.
Фраза «сайт должен быстро загружаться» не проверяется. Лучше указать инструмент, страницы и сценарии измерения, а затем сохранить исходный отчёт и результаты перед приёмкой.
Критерии приёмки превращают ожидание в проверку
У каждого важного сценария должен быть наблюдаемый результат. Удобный формат — «дано / когда / тогда».
Посетитель находится на странице услуги и форма доступна.
Он заполняет обязательные поля корректными данными и отправляет форму.
Появляется подтверждение, заявка создаётся в CRM с адресом страницы и источником, менеджер получает уведомление.
Отдельно зафиксируйте этапы согласования: кто принимает структуру, прототип, дизайн, тестовую версию и запуск. Для каждого этапа нужны срок обратной связи, формат замечаний и ответственный, который принимает окончательное решение.
Самопроверка
Чек-лист готового ТЗ на сайт
- Цель и ожидаемый результат
- Аудитории и сценарии
- Ограничения и приоритеты
- Карта страниц
- Задача каждой страницы
- Контент и ответственные
- Поля, правила и состояния
- Роли и права
- Интеграции и ошибки
- Бренд и референсы
- Адаптивное поведение
- Пустые и ошибочные состояния
- SEO и аналитика
- Скорость и доступность
- Безопасность и совместимость
- Проверяемые критерии
- Этапы согласования
- Передача доступов и документации
Частые ошибки при подготовке ТЗ
Копировать чужое ТЗ целиком. Шаблон помогает не забыть разделы, но цели, данные, процессы и ограничения у каждого проекта свои.
Описывать только внешний вид. Макеты не объясняют права доступа, интеграции, ошибки и правила обработки данных.
Использовать оценочные слова. «Удобный», «современный» и «быстрый» нужно переводить в сценарии и критерии проверки.
Не назначать владельца контента. Даже готовый сайт нельзя запустить, если тексты, фотографии и юридические документы никто не подготовил.
Забывать про ошибки и пустые состояния. Реальный пользователь может ввести неверные данные, не получить результат поиска или потерять соединение.
Не фиксировать изменения. Устные договорённости быстро расходятся; обновлённое решение должно появиться в документе и плане проекта.
Вопросы о техническом задании на сайт
Кто должен составлять техническое задание на сайт?
Лучший результат получается совместно: владелец продукта описывает цели, аудиторию и ограничения, а аналитик или разработчик переводит их в структуру, сценарии, требования и проверяемые критерии. Полностью перекладывать документ только на одну сторону рискованно.
Нужно ли ТЗ для небольшого лендинга?
Да, но объём документа должен соответствовать задаче. Для лендинга достаточно компактного брифа со структурой блоков, целевым действием, формами, источниками контента, адаптивными состояниями, аналитикой и критериями готовности.
Насколько подробным должно быть ТЗ?
Настолько, чтобы две стороны одинаково понимали результат и могли проверить его без догадок. Важнее не количество страниц документа, а отсутствие двусмысленности в сценариях, данных, состояниях интерфейса и критериях приёмки.
Можно ли менять ТЗ во время разработки?
Можно. Изменение следует зафиксировать: что меняется, почему, на какие страницы и интеграции влияет, кто подтверждает решение и как обновляются сроки этапов. Так документ остаётся актуальной картой проекта, а не архивом первоначальных идей.
Чем техническое задание отличается от прототипа?
ТЗ описывает цели, правила, данные, функции, ограничения и критерии готовности. Прототип показывает расположение элементов и путь пользователя. Они дополняют друг друга: прототип делает требования наглядными, но не заменяет правила работы системы.
Что приложить к ТЗ на сайт?
Полезны брендбук, логотипы, примеры контента, таблица товаров или услуг, перечень интеграций, доступная аналитика текущего сайта, юридические тексты, референсы с пояснениями и список ответственных за согласование.
Проверяемые материалы
Первичные источники
Официальная документация, стандарты и руководства, на которые можно опираться при проектировании решения.
Материал прочитан
Вернуться к началуБесплатная консультация
Оставьте заявкуна бесплатную консультацию
Разберём задачу, предложим подходящий формат и обозначим следующие шаги — без навязчивых продаж.
Написать в TelegramОбычно отвечаем в течение рабочего дня
Разработка сайтов · 15 мин.
