Как составить техническое задание на лендинг

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

Хорошее техническое задание не обязано быть многостраничным юридическим документом. Достаточно структурированного файла на несколько страниц, где чётко зафиксированы цели, аудитория, структура и границы работ. Разберём, из чего должно состоять такое ТЗ и какие пункты чаще всего забывают, а потом жалеют об этом на середине проекта.

Зачем вообще нужно ТЗ, если можно всё обсудить на встрече

Устная договорённость легко забывается и по-разному запоминается двумя сторонами уже через неделю. Письменное ТЗ решает две задачи одновременно: фиксирует ожидания заказчика в явном виде и защищает исполнителя от бесконечного расширения объёма работ, когда каждая новая правка добавляется «раз уж мы всё равно дорабатываем».

Хорошее ТЗ экономит деньги обеим сторонам. Заказчику — потому что итоговый результат ближе к ожиданиям с первой попытки, а не после пяти кругов правок. Исполнителю — потому что понятны границы проекта, и он может точнее посчитать сроки и стоимость на старте, не закладывая избыточный запас на неопределённость.

Цели лендинга и целевое действие

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

Часто заказчик закладывает сразу несколько равнозначных целей: «пусть можно будет и позвонить, и оставить заявку, и написать в чат, и скачать каталог». Формально это не ошибка, но на практике распыление кнопок призыва к действию снижает конверсию по каждому отдельному каналу. В ТЗ стоит явно выделить одно главное действие и, если нужно, одно-два второстепенных.

Портрет целевой аудитории

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

В ТЗ полезно указать:

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

Даже короткий абзац по каждому пункту сильно сокращает количество правок на этапе текста и дизайна.

Структура блоков

Список блоков — сердце технического задания. Здесь заказчик и исполнитель договариваются, что вообще будет на странице: оффер, преимущества, процесс работы, портфолио, цены, отзывы, часто задаваемые вопросы, форма заявки. Порядок блоков и их количество зависят от сложности продукта и от того, полулендинг это, полноценный лендинг или многостраничный сайт.

ТЗ без структуры блоков — это ТЗ только наполовину. Заказчик утверждает «текст», а не понимает, какой конкретно текст и в каком месте страницы он появится.

Полезно напротив каждого блока коротко описать его задачу: не просто «блок с преимуществами», а «блок с преимуществами — снять сомнение в сроках и качестве, три-четыре пункта с иконками». Такая формулировка задаёт направление копирайтеру ещё до того, как он начал писать текст.

Референсы и то, чего точно не должно быть

Референсы — сайты, которые заказчику нравятся по стилю, структуре или подаче — сильно ускоряют работу дизайнера, потому что показывают направление наглядно, а не через словесное описание вроде «сделайте что-то современное и стильное». Достаточно двух-трёх примеров с коротким пояснением, что именно нравится: цветовая гамма, расположение блоков, шрифт, общее настроение.

Не менее важен обратный список — чего точно не должно быть. Иногда у заказчика есть чёткие антипатии: не любит определённый цвет, не хочет анимацию, принципиально против видео на первом экране. Такие ограничения стоит проговорить сразу, иначе исполнитель узнает о них уже после того, как показал готовый вариант, и придётся переделывать заново.

Контент: кто его готовит

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

В ТЗ стоит явно зафиксировать: копирайтинг делает исполнитель на основе брифа заказчика, фотографии предоставляет заказчик либо используются стоковые изображения, логотип и фирменные цвета уже существуют или разрабатываются отдельно. Чёткое разделение зон ответственности здесь экономит недели на реальных проектах.

Технические требования и интеграции

Отдельный блок ТЗ — технические детали, которые часто забывают на старте, а потом добавляют по ходу проекта, что почти всегда увеличивает сроки. Сюда входят: система, на которой будет собран сайт, необходимость интеграции с CRM или сервисами рассылок, подключение аналитики вроде Яндекс Метрики или Google Analytics, установка Вебвизора для анализа поведения посетителей, требования к скорости загрузки и адаптивности под мобильные устройства.

Если заказчик заранее знает, что понадобится интеграция с конкретной CRM-системой или платёжным сервисом, об этом стоит сказать до начала вёрстки, а не в середине проекта — некоторые интеграции влияют на выбор технологии сборки сайта.

Сроки и этапы согласования

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

Разумный порядок этапов: сначала утверждается структура и тексты, затем на их основе — дизайн, затем вёрстка и тестирование. Изменение текста после утверждённого дизайна почти всегда требует и правок дизайна, поэтому в ТЗ полезно прямо указать, что правки на поздних этапах оплачиваются отдельно, если они выходят за рамки согласованного на предыдущем этапе.

Количество итераций правок

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

Разумная практика — прописать в ТЗ два-три круга правок на каждом крупном этапе, после чего дополнительные правки обсуждаются и оцениваются отдельно. Это не про жадность исполнителя, а про то, чтобы обе стороны заранее понимали правила игры.

Главное — договориться до начала, а не после

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

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