Самая частая причина, по которой лендинг сдают с третьего раза и с руганью, — не криворукий разработчик. Это ТЗ из одной строки: «Нужен лендинг для продажи курсов, бюджет 40 тысяч, сделайте красиво». Дальше начинается телепатия: исполнитель догадывается, что вы имели в виду под «красиво», вы недовольны результатом, он переделывает за свой счёт, злится и в следующий раз закладывает риск в цену. Все проигрывают — а виновата пустая постановка задачи.
Хорошее техническое задание на лендинг — это не бюрократия на двадцать страниц. Это девять понятных блоков, которые умещаются на пару экранов и снимают 80% будущих споров. Я разберу каждый: что писать, как собрать референсы, как описать структуру и формы и как заранее закрыть тему бесконечных правок. В конце — готовый шаблон, который можно скопировать и заполнить под себя.
Материал из раздела «Разработка ПО». Рядом — разбор цен и сравнение технологий.
Что вы узнаете из статьи
- Девять блоков, без которых ТЗ на лендинг неполное
- Как описать структуру экранов так, чтобы её поняли
- Где брать референсы и сколько их нужно
- Кто отвечает за тексты — вы или разработчик
- Как пунктом про правки сберечь нервы и бюджет
Девять блоков рабочего ТЗ
Разберём каркас. Это не жёсткий бланк — скорее список вопросов, на которые задание обязано отвечать, иначе разработчик будет додумывать сам.
Первый блок — цель и целевое действие. Чего вы хотите от страницы: заявку, звонок, оплату, запись на вебинар? Одна страница — одна цель, и весь лендинг строится вокруг неё. Второй — продукт и аудитория: что продаёте, кому, чем отличаетесь от конкурентов. Без этого дизайнер рисует вслепую.
Третий блок — структура экранов сверху вниз. Это сердце ТЗ: первый экран с оффером, блок выгод, как это работает, отзывы, цены, форма. Четвёртый — формы и заявки: какие поля, куда уходит заявка (почта, CRM, Telegram), нужно ли подтверждение. Пятый — адаптив: на каких устройствах страница обязана работать идеально.
Шестой блок — референсы и стиль, седьмой — интеграции и аналитика, восьмой — сроки, девятый — порядок правок. Последние два экономят больше всего нервов, и про них дальше отдельно. Кстати, чем детальнее эти девять блоков, тем точнее смета — из чего складывается смета, мы разбирали в соседнем материале, и почти каждая строка там завязана на ТЗ.
Референсы: показать вместо «сделайте красиво»
Слово «красиво» в ТЗ бесполезно — у каждого оно своё. Вместо прилагательных работают примеры. Соберите 5–7 лендингов, которые вам нравятся, и к каждому подпишите, что именно зацепило: «вот этот первый экран», «такая анимация кнопки», «вот эта подача цен». И пару антипримеров — «так не надо, слишком пёстро».
Где их искать. Подсмотрите у конкурентов в нише, полистайте подборки на Behance и Dribbble, загляните в каталоги шаблонов Tilda — там тысячи готовых решений, и тыкнуть пальцем в понравившееся проще, чем описать словами. Важная оговорка: референс — это направление, а не «скопируйте один в один». Слепое копирование чужого лендинга — и юридический риск, и потеря собственного лица.
Отдельно проговорите фирменные ограничения: есть ли логотип, брендовые цвета, шрифты, готовые фото. Если айдентики нет, это тоже пункт ТЗ — либо разработчик подбирает стиль сам, либо его придётся создать, и это отдельная работа. Заодно решите вопрос с технологией: иногда от референса зависит выбор инструмента, и проще сразу выбрать технологию под желаемый результат.
Тексты, правки, сроки — где рвётся чаще всего
Три пункта, на которых ломается больше всего проектов. Начну с текстов, потому что это вечный сюрприз. По умолчанию контент пишет заказчик — многие верстальщики продающих текстов не сочиняют и молча ждут готовое. Если в ТЗ нет строки «копирайтинг входит в работу», считайте, что тексты на вас. Нет текста — нет верстки, и проект встаёт на старте. Решите это заранее: пишете сами, нанимаете копирайтера или платите разработчику, который такое умеет.
Теперь правки — главный источник конфликтов. Формулировка «правим, пока вам не понравится» убивает и сроки, и отношения. Честная схема: пропишите число кругов прямо в ТЗ. Например — два круга правок на этапе макета и один на этапе верстки, всё сверху по согласованной ставке. Это не жадность исполнителя, это защита обеих сторон от бесконечности.
И сроки. Указывайте не только финальную дату, но и контрольные точки: когда готов прототип, когда дизайн, когда верстка. Так вы видите прогресс и ловите расхождение с ожиданиями на ранней стадии, а не за день до дедлайна. И сразу договоритесь, как принимаете результат — это отдельная тема, как принять готовую работу без сюрпризов.
Готовый шаблон ТЗ — копируйте
Чтобы не собирать с нуля, вот рабочий каркас. Заполните под себя — и большая часть будущих споров отвалится сама.
| Блок | Что заполнить |
|---|---|
| Цель | целевое действие: заявка / звонок / оплата |
| Продукт и ЦА | что продаём, кому, отличие от конкурентов |
| Структура | экраны сверху вниз, по пунктам |
| Формы | поля, куда уходит заявка, подтверждение |
| Адаптив | устройства: десктоп, планшет, мобайл |
| Референсы | 5–7 примеров с пометками + антипримеры |
| Интеграции | CRM, аналитика, мессенджеры, оплата |
| Сроки | контрольные точки + финальная дата |
| Правки | число кругов, ставка за сверхлимит |
Совет напоследок: не пытайтесь написать идеальное ТЗ в одиночку. Покажите черновик разработчику до старта — хороший исполнитель подскажет, где вы недосказали, а где требуете лишнего. Это нормальная практика, и она ещё на берегу убирает половину недопониманий.
Как платформа помогает с ТЗ
На Где.Эксперт задачу можно описать в свободной форме, а отклики приходят от разработчиков, которые уже видели сотни похожих проектов. В диалоге исполнитель сам задаёт уточняющие вопросы — про формы, интеграции, сроки — и фактически помогает довести ваше ТЗ до рабочего состояния ещё до начала работы.
Это снимает страх «а вдруг я что-то упустил»: упущенное всплывает в переписке, а не на сдаче. Все договорённости остаются в чате заявки — и если возникнет спор о том, что входило в задачу, есть на что опереться. Оплата по факту, отзывы прошлых клиентов на виду.
Часто задаваемые вопросы
Обязательно ли составлять ТЗ?
Формально нет, но без него почти гарантированы переделки и споры. Даже короткое задание — структура, цель, референсы, формы — экономит недели. Чем точнее задача, тем меньше риска в смете.
Что обязательно должно быть в ТЗ?
Девять блоков: цель и целевое действие, продукт и аудитория, структура экранов, формы и куда уходят заявки, адаптив, референсы, интеграции и аналитика, сроки, порядок правок.
Кто пишет тексты?
По умолчанию заказчик, если копирайтинг отдельно не прописан как услуга. Многие верстальщики ждут готовый контент. Нет текста — обсудите заранее.
Как закрыть тему бесконечных правок?
Пропишите число кругов в цене — например, два на дизайне и один на верстке. Сверх лимита — по согласованной ставке.
Нужно ли указывать технологию?
Желательно, но не обязательно. Есть предпочтение или ограничение — укажите. Нет — доверьте выбор разработчику, описав требования к скорости и поддержке.
Заключение
Хорошее ТЗ на лендинг — это не толстый документ, а девять чётких блоков на пару экранов: цель, продукт, структура, формы, адаптив, референсы, интеграции, сроки и правила правок. Каждый из них закрывает конкретную дыру, в которую иначе утекают недели и нервы.
Запомните главное: показывайте референсы вместо слова «красиво», заранее решайте, кто пишет тексты, прописывайте число кругов правок в цене и фиксируйте контрольные точки по срокам. И не стесняйтесь показать черновик ТЗ разработчику до старта — он подскажет, где вы недосказали. Тогда лендинг сдадут с первого раза, а не с третьего.
Найдите разработчика на Где.Эксперт — опишите задачу, получите уточняющие вопросы от исполнителя и платите по факту выполнения.