Как написать ТЗ на разработку сайта или лендинга

Хорошее ТЗ на разработку сайта или лендинга должно отвечать на один вопрос: что именно подрядчик должен сделать и каким должен быть результат. Если этого нет, проект быстро уходит в бесконечные правки, споры и лишние расходы. Быстро собрать понятное ТЗ можно через генератор Utily: он помогает не забыть ключевые блоки и сразу оформить основу документа.

Попробовать инструмент Utily: Генератор ТЗ на сайт

Основная инструкция

ТЗ на сайт — это не “текст для разработчика” и не длинный документ ради формальности. Это рабочая схема проекта, в которой заранее зафиксированы:

• цель сайта;
• структура;
• функциональность;
• контент;
• дизайн-ориентиры;
• сроки и этапы;
• критерии готовности.

Чем точнее это описано, тем меньше шансов, что вы и подрядчик будете по-разному понимать результат.

Какие задачи решает ТЗ

Хорошее ТЗ помогает:

• сократить количество переделок;
• быстрее согласовать проект;
• понять реальный объём работ;
• сравнить подрядчиков по одной логике;
• защититься от фраз вроде “это не входило”;
• быстрее принять готовый результат.

Для сайта или лендинга это особенно важно, потому что даже простой проект легко расползается по объёму, если требования не зафиксированы заранее.

Что обязательно должно быть в ТЗ на сайт или лендинг

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

1. Цель проекта

Сначала нужно зафиксировать, зачем вообще делается сайт.

Например:

• получать заявки;
• собирать контакты;
• презентовать услугу;
• продавать конкретный продукт;
• запускать рекламу на лендинг;
• дать клиенту понятную точку входа в бизнес.

Плохая формулировка:

• “Нужен современный сайт”.

Лучше:

• “Нужен лендинг для рекламы услуги банкротства физлиц с целью получения заявок через форму и звонки”.

Цель влияет на структуру, контент, дизайн и метрики.

2. Тип сайта

Нужно сразу указать, что именно делаете:

• одностраничный лендинг;
• многостраничный сайт;
• корпоративный сайт;
• сайт-визитка;
• каталог;
• промостраница;
• сайт под конкретную рекламную кампанию.

Если это лендинг, важно так и написать. Если многостраничный сайт — указать, какие страницы нужны.

3. Целевая аудитория

Подрядчик должен понимать, для кого делается сайт.

Нужно коротко описать:

• кто клиент;
• какую проблему он решает;
• что для него важно;
• почему он должен оставить заявку именно здесь.

Например:

• собственники малого бизнеса;
• родители школьников;
• владельцы квартир в новостройках;
• b2b-клиенты, которым важно быстро понять условия и кейсы.

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

4. Структура сайта

Это один из самых важных блоков.

Нужно перечислить:

• какие страницы или блоки будут на сайте;
• в каком порядке они идут;
• какие элементы обязательны.

Для лендинга структура может быть такой:

1. Первый экран
2. Описание услуги
3. Для кого подходит
4. Преимущества
5. Кейсы или отзывы
6. Этапы работы
7. FAQ
8. Форма заявки
9. Контакты

Для многостраничного сайта — например:

• Главная
• О компании
• Услуги
• Кейсы
• Цены
• FAQ
• Контакты

Если структуру не зафиксировать, подрядчик будет придумывать её сам, и это не всегда совпадёт с вашей задачей.

5. Функциональность

Здесь нужно указать, что сайт должен уметь.

Например:

• форма заявки;
• кнопка звонка;
• интеграция с CRM;
• квиз;
• онлайн-чат;
• карта;
• каталог;
• фильтры;
• калькулятор;
• скачивание PDF;
• подключение аналитики;
• подключение пикселей рекламы.

Не надо писать абстрактно “нужен функциональный сайт”. Лучше перечислить конкретные действия пользователя и нужные механики.

6. Контент

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

Нужно заранее указать:

• кто готовит тексты;
• кто подбирает изображения;
• нужны ли иконки и иллюстрации;
• будут ли фото команды, офиса, товаров;
• кто даёт документы и кейсы;
• кто согласует контент.

Частая проблема: технически сайт можно собрать быстро, но проект встаёт, потому что никто не знает, кто должен прислать тексты и материалы.

7. Дизайн-ориентиры

Необязательно писать большой дизайн-раздел, но базовые ориентиры нужны.

Можно указать:

• желаемый стиль;
• референсы;
• цветовые ограничения;
• фирменный стиль;
• строгий или эмоциональный тон;
• чего точно не должно быть.

Например:

• “Нужен сдержанный деловой стиль без перегруза анимацией”
• “Ориентир на сайты юридических услуг”
• “Не использовать визуально агрессивные цвета”
• “Важно, чтобы сайт хорошо выглядел на телефоне”

Это помогает сократить субъективные споры на этапе дизайна.

8. Мобильная версия

Этот пункт лучше писать отдельно, а не “по умолчанию”.

Нужно зафиксировать, что сайт должен:

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

Для лендингов это особенно важно, потому что значительная часть трафика идёт с телефона.

9. SEO и аналитика

Даже если проект небольшой, лучше сразу указать базовые требования.

Например:

• возможность задать title и description;
• человекопонятные URL;
• подключение Яндекс Метрики и Google Analytics;
• подключение рекламных пикселей;
• формы с отслеживанием отправки;
• базовая SEO-структура заголовков.

Если это лендинг под рекламу, акцент может быть на аналитике. Если многостраничный сайт — на SEO-основе.

10. Сроки и этапы

Нужно понять, как проект будет идти по шагам.

Например:

• сбор материалов;
• прототип;
• дизайн;
• вёрстка;
• разработка;
• тестирование;
• публикация;
• финальная передача.

Полезно указать:

• сроки этапов;
• кто согласует;
• сколько времени даётся на обратную связь;
• сколько раундов правок включено.

Если этого нет, проект легко растягивается на месяцы.

11. Критерии готовности

Очень важный блок, который часто забывают.

Нужно зафиксировать, что считается готовым результатом.

Например:

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

Без этого приёмка превращается в спор “ну вроде уже всё готово”.

Пошаговая схема: как написать ТЗ быстро

Шаг 1. Зафиксируйте цель сайта

Сначала ответьте на вопрос: что должен делать сайт для бизнеса?

Не “быть красивым”, а:

• давать заявки;
• объяснять услугу;
• собирать контакты;
• вести на звонок;
• конвертировать рекламный трафик.

Шаг 2. Опишите структуру

Нужно перечислить страницы или блоки в логическом порядке.

Даже черновая структура уже сильно упрощает работу подрядчику.

Шаг 3. Опишите функции

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

Шаг 4. Определите, кто отвечает за контент

Это один из самых практичных шагов. Если не закрепить это сразу, проект почти гарантированно начнёт тормозить.

Шаг 5. Зафиксируйте ограничения и ориентиры

Сюда входят:

• стиль;
• референсы;
• технические ограничения;
• обязательные интеграции;
• пожелания по мобильной версии;
• ограничения по CMS или платформе, если они есть.

Шаг 6. Зафиксируйте, что считается готовым результатом

Именно это потом поможет принять сайт без лишних споров.

Пример

Ниже — пример упрощённого ТЗ на лендинг для услуги.

Пример структуры ТЗ

Проект: лендинг для услуги бухгалтерского сопровождения малого бизнеса

Цель: получать заявки с контекстной рекламы и органики

Целевая аудитория: ИП и небольшие ООО, которым нужен аутсорс бухгалтерии

Структура лендинга:

1. Первый экран с оффером и кнопкой заявки
2. Услуги и тарифы
3. Для кого подходит
4. Преимущества
5. Кейсы / отзывы
6. Этапы работы
7. FAQ
8. Форма заявки
9. Контакты

Функции:

• форма заявки;
• кнопка звонка;
• квиз на 3–5 вопросов;
• интеграция заявок в CRM;
• подключение Яндекс Метрики.

Контент:

• тексты готовит заказчик на основе интервью;
• кейсы и отзывы предоставляет заказчик;
• изображения подбирает подрядчик;
• финальное согласование текстов — со стороны заказчика.

Дизайн:

• спокойный деловой стиль;
• без агрессивной анимации;
• акцент на доверии и понятности;
• приоритет мобильной версии.

Сроки:

• прототип — 5 рабочих дней;
• дизайн — 5 рабочих дней после согласования прототипа;
• сборка — 7 рабочих дней;
• тестирование — 2 рабочих дня.

Критерии готовности:

• все блоки собраны;
• формы работают;
• сайт открыт на домене;
• аналитика подключена;
• мобильная версия проверена;
• переданы доступы.

Что даёт такой формат

Даже без большого юридического документа уже понятно:

• что именно нужно сделать;
• какой должен быть результат;
• кто за что отвечает;
• как проект принимать.

Этого часто достаточно, чтобы подрядчик дал адекватную оценку и не “расширял” объём по ходу работы без вашего понимания.

Когда это использовать

Такой формат ТЗ особенно полезен, если вы:

• заказываете первый сайт или лендинг;
• работаете с внешним подрядчиком;
• запускаете страницу под рекламу;
• не хотите объяснять задачу устно по десять раз;
• хотите сравнить несколько исполнителей по одной и той же логике;
• хотите сократить количество правок и недопонимания;
• собираете проект без собственного проджекта или маркетолога.

Это особенно полезно малому бизнесу, где один неудачный запуск сайта может стоить заметно дороже, чем час на нормальное ТЗ.

Типичные ошибки

1. Писать вместо ТЗ набор пожеланий

Фразы вроде “хотим современно и продающе” не помогают. Подрядчику нужны конкретные требования, а не ощущения.

2. Не фиксировать структуру

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

3. Не определить, кто даёт контент

Это одна из самых частых причин затяжки сроков.

4. Не описывать функциональность отдельно

Если не прописать форму, аналитику, интеграции и другие элементы, потом они могут оказаться “не включены”.

5. Не зафиксировать критерии готовности

Без этого сложно понять, когда сайт действительно готов, а когда подрядчик считает, что уже всё закончил.

FAQ

Нужно ли писать большое ТЗ на простой лендинг?

Не обязательно большое, но понятное — обязательно. Даже короткое ТЗ лучше, чем проект “на словах”.

Кто должен писать ТЗ: заказчик или подрядчик?

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

Нужно ли включать в ТЗ тексты блоков?

Не всегда. Но нужно точно указать, кто их готовит и в каком объёме.

Что важнее: дизайн или структура?

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

Можно ли использовать одно и то же ТЗ для разных подрядчиков?

Да. Это даже удобно, потому что позволяет сравнивать предложения на одинаковой базе.

Похожие задачи

После ТЗ на сайт или лендинг обычно полезно подготовить ещё два документа:

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

Если не хотите собирать структуру вручную с нуля, удобнее сначала сделать черновик в Utily и уже потом доработать его под конкретный проект.

Собрать ТЗ в Utily: Генератор ТЗ на сайт