Техническое задание на сайт — это документ, в котором заказчик описывает, какой сайт ему нужен и зачем: цель бизнеса, кому сайт адресован, из каких блоков состоит, какие смыслы должен донести и какими доказательствами их подпереть. Без него исполнитель — агентство, фрилансер или нейросеть — додумывает задачу за вас, и результат почти всегда расходится с ожиданием.
В этой статье разберём, что должно быть в ТЗ на сайт, чем задание для ИИ-билдера отличается от задания для подрядчика, и покажем настоящий пример: полный документ на 36 000 знаков, собранный за один диалог под конкретную клинику.
Что такое ТЗ на сайт простыми словами
Техническое задание на сайт (ТЗ) — это письменная договорённость о том, что именно будет сделано. Не список хотелок и не описание дизайна, а документ, который отвечает на четыре вопроса: зачем нужен сайт, для кого он, что на нём будет и как понять, что работа выполнена.
Обычно ТЗ пишет заказчик — сам или вместе с исполнителем. Иногда его составляет подрядчик по итогам брифа и отдаёт клиенту на утверждение. Кто именно держит перо, не так важно. Важно, что документ существует и обе стороны с ним согласились до начала работ.
Слово «техническое» здесь сбивает с толку. В хорошем ТЗ на сайт почти нет техники: ни языков программирования, ни требований к серверу. Есть бизнес-задача, аудитория, структура страниц, смыслы и тексты. Всё остальное исполнитель решит сам — это его работа.
Что на самом деле решает техническое задание
Три вещи, ради которых документ вообще пишется.
Оно синхронизирует заказчика и исполнителя. У вас в голове один сайт, у подрядчика — другой. Пока картинки живут только в головах, они кажутся одинаковыми: оба говорят «современный, удобный, продающий». Расхождение вскрывается на приёмке, когда переделывать дорого и поздно.
Оно фиксирует объём работ. Без ТЗ любая просьба выглядит как «мелкая правка»: добавить раздел, переделать блок, вставить калькулятор. Для исполнителя это дни работы, для заказчика — минутное пожелание. Из этого рождаются конфликты, срывы сроков и суммы, которые растут по ходу дела.
Оно даёт критерий приёмки. Вопрос «сайт готов или нет» без документа решается ощущениями: заказчику «как-то не то», подрядчику «всё сделано». С ТЗ ответ проверяемый: вот пункт, вот его исполнение.
> Практическое наблюдение: чем меньше опыта у заказчика, тем важнее ТЗ. Опытный клиент поймает расхождение на третий день. Новичок увидит его на сдаче.
Почему сайты получаются не такими, как задумывал заказчик
Причина почти всегда одна и та же — разрыв между «что я хочу» и «что я сказал».
Заказчик приходит с формулировкой «нужен современный продающий сайт». В его голове за этими словами стоит многое: конкретные клиенты, их сомнения, свои преимущества, опыт разговоров с покупателями. Ничего из этого он не произнёс — потому что для него это очевидно, а очевидное не проговаривают.
Исполнитель слышит «современный, продающий» и делает то, что под этим понимает сам: аккуратную вёрстку, красивые блоки, кнопку «Оставить заявку». Формально задача выполнена. Заявок нет.
Вот типичные пары «сказано — понято»:
ТЗ существует ровно для того, чтобы правая колонка была написана, а не подразумевалась.
Цель проекта — пункт, который меняет весь документ
Самая частая дыра в техническом задании — отсутствие цели. Есть перечень страниц, есть требования к дизайну, а зачем всё это — не сказано.
Цель должна быть сформулирована в терминах бизнеса, а не сайта. Сравните:
- ❌ «Сделать современный сайт стоматологии с разделами: главная, услуги, врачи, цены, контакты»
- ✅ «Получать заявки на консультацию по имплантации — средний чек 90–180 тысяч рублей. Сейчас такие пациенты приходят только по сарафану. Нужно, чтобы человек, который боится имплантации, перестал бояться и записался на бесплатную консультацию с КТ»
Первая формулировка ничего не задаёт: под неё подойдёт любой сайт клиники. Из второй сразу следует структура: раз человек боится — значит нужны блоки, снимающие страх; раз чек высокий — значит одной кнопки мало, нужны доказательства; раз первый шаг бесплатный — значит он и должен стоять на первом экране.
Одна правильно написанная цель определяет половину документа. Если в вашем ТЗ её нет, остальные пункты пишутся наугад.
Отдельно проговорите целевое действие: что конкретно должен сделать посетитель. Позвонить, оставить телефон, записаться на дату, скачать прайс, написать в мессенджер. От этого зависит вся конструкция страницы, а формулировка «оставить заявку» слишком расплывчата — заявку на что и в каком виде.
Смыслы и артефакты: чего нет в обычных ТЗ
Здесь проходит граница между заданием, по которому получается обычный сайт, и заданием, по которому получается работающий.
Смысл — это причина выбрать вас, сформулированная на языке клиента. Не «индивидуальный подход» и не «высокое качество», а конкретное утверждение, которое человеку важно услышать. «Имплантолог ведёт вас сам от первого снимка до готовой коронки, не передаёт другому врачу» — это смысл. «Профессиональная команда специалистов» — это шум.
Артефакт — это доказательство смысла. Фото, документ, цифра, видео, скриншот, отзыв с именем, сертификат. Смысл без артефакта — обещание, которых человек уже прочитал десяток на сайтах конкурентов.
Пара работает только вместе:
Подробный разбор того, как смыслы добываются и как выстраиваются в структуру страницы, — в отдельном материале про смысловую упаковку в маркетинге. Здесь важно другое: в ТЗ под каждый смысловой блок должно быть указано, каким артефактом он подпирается. Иначе на сайте появится красивый заголовок и пустота под ним.
Что должно быть в техническом задании на сайт: 12 разделов
Рабочий состав документа. Первые семь пунктов обязательны всегда, остальные — по ситуации.
Про дизайн стоит сказать отдельно. Слова «строго, но дорого» ничего не передают: у каждого человека за ними своя картинка. Референс — обязательный пункт. Три-четыре ссылки на сайты, которые нравятся, с пояснением, что именно нравится: палитра, типографика, ощущение. Смотреть примеры удобно на Behance и Dribbble, а также просто среди сайтов конкурентов в вашей нише.
ТЗ для агентства и ТЗ для нейросети — это два разных документа
Большинство образцов в интернете написаны для подрядчика-человека. Если отдать такой документ ИИ-билдеру, результат разочарует — и дело не в нейросети.
Главное отличие: нейросеть не переспрашивает. Человек, получив невнятное «сделайте красиво и продающе», позвонит и уточнит. ИИ-билдер молча заполнит пробел собственной фантазией — и выдаст обобщённый сайт «для стоматологии вообще», без вашего врача, вашей лаборатории и ваших пациентов.
Отсюда простое следствие: чем подробнее задание, тем меньше похоже, что сайт сделан нейросетью. Претензия «ИИ делает шаблонные сайты» почти всегда означает «на вход подали шаблонное описание». Подробнее о том, как этот подход устроен изнутри и где его границы, — в статье про вайбкодинг.
Второе следствие важно для тех, кто пишет ТЗ впервые: не вставляйте в задание для билдера технические указания. Требования «сделать на React, подключить PostgreSQL» либо будут проигнорированы, либо утянут внимание модели с содержания на форму. Ваша часть — смыслы, структура, тексты, дизайн. Техническую часть платформа выбирает сама.
Как составить ТЗ на сайт: пять шагов
Порядок, в котором документ собирается быстрее всего.
Шаг 1. Записать вводные. Ниша, город, что продаёте, средний чек, цель проекта, откуда сейчас идут клиенты. Пять-семь предложений, без причёсывания.
Шаг 2. Разобрать аудиторию. Кто ваши покупатели, разбить на 3–5 сегментов. По каждому: какую задачу человек решает, чего боится, какое возражение произносит вслух и какое имеет в виду на самом деле. Этот шаг пропускают чаще всего — и именно он даёт структуру.
Шаг 3. Посмотреть на конкурентов. Не для того, чтобы скопировать, а чтобы понять, что читатель уже видел десять раз. Если все вокруг пишут «опытные врачи и современное оборудование», эти слова у вас не сработают.
Шаг 4. Выбрать структуру. Порядок блоков — это не вкусовщина, а логика снятия сомнений: сначала попасть в проблему, потом показать решение, потом доказать, потом снять возражение, потом позвать. Один сдвинутый блок меняет конверсию: цены, спрятанные в подвал, заставляют людей уходить искать их у конкурента.
Шаг 5. Наполнить смыслами и артефактами. По каждому блоку: заголовок, основная мысль, чем подтверждается, что человек делает дальше.
Пятый шаг — самый трудоёмкий. Именно на нём документ либо становится рабочим, либо превращается в оглавление.
Пример ТЗ на сайт: живой прогон для стоматологии
Чтобы показать разницу между «списком страниц» и настоящим заданием, мы прогнали реальный сценарий через генератор смыслов и технических заданий — наш инструмент из раздела «Инструменты». Ниже — что он спрашивал и что выдал, без правок с нашей стороны.
Вводные заказчика были обычными, такими, какие приходят в жизни:
> «Частная стоматология, Ростов-на-Дону, спальный район, рядом две сетевые клиники. Сейчас только страница ВКонтакте и запись по телефону. Нужны заявки на имплантацию — средний чек 90–180 тысяч. Есть имплантолог с 18-летним стажем, своя зуботехническая лаборатория, рассрочка, 120 отзывов на Яндекс.Картах со средней 4,8».
Дальше — диалог из четырёх шагов. Ассистент не бросился писать документ, а сначала разобрал аудиторию.
Что он выдал на шаге анализа
Четыре сегмента, и по каждому — задача, смыслы, страхи. Например, сегмент «Беглец от протеза», 45–65 лет:
> Задача: снова нормально есть, перестать стесняться улыбаться, один раз решить проблему и забыть.
> Важные смыслы: имплант — это не протез, это свой зуб; решается навсегда; можно в рассрочку.
> Истинные возражения: «это очень больно» · «не приживётся, потеряю деньги» · «90 тысяч — не потяну» · «уже поздно, кость не та» · «это долго, несколько лет».
Отдельно всплыло то, чего в вводных не было: возражение «дорого» у этой аудитории почти всегда означает не «нет денег», а «боюсь переплатить и получить плохо». Это разные возражения, и закрываются они разными блоками.
Что получилось на выходе
Итоговый документ — 36 000 знаков, 13 частей: дизайн-система, архитектура сайта, 15 блоков главной страницы, четыре внутренние страницы, квиз, страница благодарности, правила для мобильной версии и список вопросов, которые билдер должен задать владельцу до начала работы.
Вот как в нём выглядит первый экран — не «блок с оффером», а готовый к сборке текст:
> БЛОК 1: HERO
> Задача блока: с первых секунд попасть в реальный страх пациента и предложить другой путь.
> Заголовок: «Боитесь имплантации — или боитесь снова заплатить и получить не то?»
> Подзаголовок: «Имплантолог с 18-летним стажем и 3 000+ успешных имплантаций ведёт вас сам — от первого снимка до готовой коронки. Бесплатная консультация с КТ и планом лечения на руки, без обязательств».
> Три буллета: КТ бесплатно — стоимость 3 500 ₽, для вас 0 ₽ · Пожизненная гарантия на имплант, письменно в договоре · Своя лаборатория в этом здании — коронка без ожидания.
> Строка доверия под формой: «120 отзывов на Яндекс.Картах · Рейтинг 4,8 · Западный район, Ростов-на-Дону».
Обратите внимание на два места. Заголовок бьёт не в услугу, а в настоящий страх — тот самый, который вскрылся на шаге анализа. А бесплатное КТ подано не как «бесплатная консультация», а с зачёркнутой ценой: 3 500 ₽ → 0 ₽. Разница в одной строке, а воспринимается совсем иначе.
И ещё один блок, которого не было в исходном запросе, — его попросил добавить сам заказчик после анализа:
> БЛОК 6: ПЕРЕДЕЛКА ЧУЖИХ РАБОТ — отдельный смысл для людей, которым уже сделали плохо в другой клинике. С диагностикой, без осуждения, со снимками до и после.
Такие блоки не появляются из списка страниц. Они появляются, когда сначала разбирают аудиторию, а потом строят структуру.
Пять ошибок, которые убивают техническое задание
1. Документ описывает страницы, а не смыслы. «Главная, о нас, услуги, контакты» — это оглавление, а не задание. По нему получится сайт-визитка, даже если заказывали продающий.
2. Нет ни одного артефакта. Все обещания идут без доказательств: «опытные специалисты», «гарантия качества», «индивидуальный подход». Такой сайт неотличим от соседнего.
3. Дизайн описан словами. «Строго, но современно, чтобы дорого смотрелось» — это не требование, а ощущение. Нужны ссылки на конкретные примеры.
4. Переписаны требования конкурента. Структура, которая работает у сетевой клиники с известным брендом, не работает у частной: у них задача — удержать поток, у вас — заслужить доверие с нуля.
5. Технические требования вместо содержания. Три страницы про хостинг, CMS и языки — и ни строчки про то, кому и что сайт должен сказать. Классическая ошибка при переносе шаблона ТЗ из закупок 44-ФЗ на коммерческий сайт.
Как проверить готовое ТЗ: десять вопросов
Пройдите по списку до того, как отдавать документ в работу. Каждое «нет» — это будущая переделка.
- Сформулирована ли цель в терминах бизнеса, а не сайта?
- Указано ли конкретное целевое действие посетителя?
- Разобрана ли аудитория хотя бы на три сегмента?
- Записаны ли настоящие возражения — те, что люди произносят в переписке и по телефону?
- Есть ли под каждым смыслом артефакт?
- Понятно ли, что стоит в каждом блоке и в каком порядке?
- Есть ли ссылки-референсы, а не описание дизайна словами?
- Указано ли, кто пишет тексты?
- Понятно ли, куда падают заявки и кто их обрабатывает?
- Можно ли по документу проверить готовую работу?
Если документ идёт в ИИ-билдер, добавьте одиннадцатый: не осталось ли в нём мест, где исполнителю придётся догадываться. Человек догадается, нейросеть — нет.
Куда нести готовое ТЗ
Хорошее задание универсально: оно одинаково подходит агентству, фрилансеру и нейросети. Разница только в том, что происходит дальше.
- ИИ-билдер — собирает сайт по тексту задания за один заход. Например, российская платформа Ноя: сайт собирается в диалоге, SEO-обвязка, карта сайта и приём заявок идут из коробки, домен подключается свой. Как это выглядит на практике — в разборе создания сайта для бизнеса с помощью ИИ и в кейсе про сайт за 70 минут.
- Подрядчик — получает документ, по которому нечего додумывать, и не сможет сослаться на «вы так и не сказали, чего хотите».
- Вы сами — если делаете сайт своими руками, ТЗ становится планом работы: блок за блоком, без метаний.
Если сайт одностраничный, полезно заранее посмотреть, как устроен лендинг и в каких случаях выгоднее квиз-лендинг — от этого зависит структура в шестом разделе задания.
FAQ
Кто должен писать техническое задание на сайт — заказчик или исполнитель?
Содержательную часть — заказчик: только он знает бизнес, клиентов и преимущества. Исполнитель помогает с формой и задаёт вопросы. На практике лучше всего работает диалог: подрядчик или ассистент спрашивает, заказчик отвечает, документ собирается из ответов.
Сколько страниц должно быть в ТЗ на сайт?
Объём не показатель. Для одностраничника достаточно 5–10 страниц текста, для многостраничного сайта выходит 20–40. Важнее другое: нет ли в документе мест, где исполнителю придётся угадывать.
Чем ТЗ отличается от брифа?
Бриф — это анкета с вопросами к заказчику, вход. ТЗ — итоговый документ с решениями, выход. Бриф заполняют за полчаса, ТЗ собирают из его ответов.
Нужно ли ТЗ, если я делаю сайт сам в конструкторе?
Да, и это как раз тот случай, когда оно окупается быстрее всего. Без задания вы будете переделывать блоки по кругу, потому что не решили заранее, что и в каком порядке говорите. С заданием сборка превращается в механическую работу.
Можно ли взять готовый шаблон ТЗ из интернета?
Как каркас — можно. Но почти все шаблоны в выдаче написаны под подрядчика-человека и под корпоративные сайты: там много про CMS, хостинг и сроки и почти ничего про смыслы и аудиторию. Для сайта, который должен приносить заявки, важна именно вторая часть.
Что писать в ТЗ, если у меня нет фотографий и отзывов?
Так и написать: какие артефакты есть, какие нужно собрать, а где временно ставится заглушка. Это честнее, чем промолчать: иначе исполнитель поставит стоковую картинку, и блок доверия превратится в блок недоверия.
Как понять, что ТЗ достаточно подробное для нейросети?
Простой тест: дайте документ человеку, который не знает ваш бизнес, и спросите, что он поставит в третьем блоке. Если ответ совпадает с вашим замыслом — задание готово. Если человек задаёт уточняющие вопросы, нейросеть на этих же местах придумает что-то своё.
Вывод
Техническое задание — это не бюрократия и не формальность перед договором. Это единственный способ передать другому человеку или нейросети то, что у вас в голове, без потерь.
Три вещи, которые отличают рабочее ТЗ от формального:
- цель написана в терминах бизнеса, а не в перечне страниц;
- у каждого смысла есть артефакт, который его доказывает;
- не осталось мест, где исполнителю нужно догадываться.
Всё остальное — детали оформления. А если документ пишется для ИИ-билдера, третий пункт становится главным: нейросеть не переспросит, она просто заполнит пробел за вас.
