Как составить ТЗ на редизайн лендинга: пошаговый гид

Как составить ТЗ на редизайн лендинга: пошаговый гид

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

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

1. Когда редизайн лендинга нужен, а когда достаточно точечных правок

Редизайн нужен, если лендинг устарел по смыслу. Например, продукт уже другой, оффер изменился, а на первом экране все еще обещают то, что компания больше не продает. Это типичная ситуация для B2B и услуг, где меняется упаковка, а страница живет прошлым.

Еще один сигнал — падение конверсии. Не абстрактное “стало хуже”, а конкретное: заявки просели после смены трафика, вырос процент отказов на мобильных, пользователи не доходят до формы. В такой ситуации точечная правка текста не спасает, потому что проблема сидит глубже, в логике страницы.

Иногда достаточно точечной доработки. Если один блок ломает весь экран, а остальная структура работает, редизайн сайта будет лишним. Достаточно заменить первый экран, сократить форму или переписать CTA. Лендинг не обязан переживать полную пересборку из-за одной слабой кнопки.

Есть и внешние причины. Бренд обновил визуальный стиль, сменил логотип, палитру, тон общения. Тогда старая страница выглядит чужой. А бывает наоборот: визуально все красиво, но мобильная версия неудобна, и на смартфоне форма уезжает вниз, из-за чего часть пользователей просто закрывает страницу.

Тут полезно разделять “нравится” и “не работает”. Если спор идет только о вкусе, редизайн сайта можно отложить. Если есть конкретная потеря заявок, конверсии или доверия, редизайн лендинга уже оправдан.

2. Что собрать до начала работ: цели, ограничения и исходные данные

Перед тем как писать ТЗ, соберите 5 групп вводных: цели, аудиторию, текущие проблемы, ограничения и материалы. Без этого любое описание задачи получится размытым. Исполнитель увидит общие слова, а не задачу.

Начните с текущих метрик. Нужны не “плохие показатели”, а конкретные числа: конверсия, глубина скролла, клики по форме, поведение на мобильных. Если аналитика подключена, отметьте, на каком шаге пользователи чаще всего уходят. Если метрик нет, так и пишите — это тоже информация, а не пробел в ТЗ.

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

Полезно приложить список проблемных блоков. Не “страница перегружена”, а конкретно: первый экран, блок преимуществ, форма заявки, отзывы, FAQ. Если есть доступы к CMS, аналитике, рекламному кабинету или CRM, это тоже стоит перечислить. Пустая фраза “доступы есть” не поможет, если потом окажется, что логин хранится у бывшего подрядчика.

В ТЗ пригодятся и бренд-материалы: логотип, фирменные цвета, шрифты, гайдлайн, фотографии, старые презентации, кейсы. Если их нет, зафиксируйте это отдельно. Еще нужны референсы, но не в виде “нравится все”. Лучше 2-3 примера с пояснением: у этого нравится первый экран, у того — форма, у третьего — подача доверия.

Сроки и платформа тоже идут в исходные данные. Лендинг может жить на Tilda, Webflow, WordPress или в самописной системе. Если платформа ограничивает анимации, сетку или типы блоков, это нужно написать заранее. Иначе исполнитель спроектирует то, что потом не удастся собрать без переделок.

3. Как описать задачу для фрилансера: чтобы ТЗ было понятным и исполнимым

Когда вы готовите ТЗ для фрилансера, не расписывайте биографию проекта. Фрилансеру нужен объем работ, границы ответственности и критерий, по которому вы примете результат. Все остальное — шум.

Хорошая формулировка звучит так: “Нужно обновить структуру и визуальную подачу лендинга, сохранить тексты из блока X и Y, предложить новую логику первого экрана и формы заявки, подготовить макет для адаптива 375 и 1440”. Здесь уже есть объем, ограничения и формат результата. И нет лишней воды.

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

Коммуникацию тоже стоит описать. Например, “согласование в Telegram, финальные комментарии в Figma, 2 контрольные точки: после прототипа и после основного экрана”. Для человека на фрилансе это яснее, чем размытое “быть на связи”. Если нужен подрядчик через площадку, можно посмотреть [проекты и задания](https://profreelance.biz/feed/) и сразу сверить, как обычно формулируют ожидания заказчики.

Критерии приемки пишите без эмоций. Не “чтобы выглядело современно”, а “первый экран содержит оффер, подзаголовок, CTA и визуальный акцент; форма заметна без прокрутки; на мобильной версии текст не обрезается”. Чем меньше вкусовых слов, тем спокойнее будет сдача. ТЗ для фрилансера любит конкретику.

4. Пошаговая структура ТЗ на редизайн лендинга

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

1. Цель редизайна.
2. Краткий аудит текущей версии.
3. Целевая аудитория и сценарии.
4. Требования к структуре и блокам.
5. Требования к дизайну и адаптиву.
6. Сроки, этапы и согласование.
7. Критерии приемки.

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

Аудит текущей версии не должен быть длинным. Достаточно 5-7 пунктов: что работает, что мешает, где теряется внимание, где ломается путь к форме. Если есть конкретные наблюдения по поведению пользователей, добавьте их. Это помогает обосновать, почему вообще нужен редизайн сайта, а не новая шапка.

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

Сроки тоже лучше разбить на этапы. Например: прототип, дизайн первого экрана, полный макет, финальная правка. Когда есть этапы, проще держать контроль и не ждать “почти готово” неделями. Для заказчика это еще и понятный способ оценить прогресс.

5. Что обязательно описать в блоках лендинга: смысл, контент и CTA

Каждый блок на лендинге должен иметь смысл. Если блок существует только потому, что “так принято”, его лучше пересмотреть. В ТЗ полезно писать не только название блока, но и его задачу: информировать, убедить, снять страх, подтолкнуть к заявке.

Первый экран описывают особенно подробно. Здесь нужен оффер, короткое пояснение, один главный CTA и, если уместно, визуальный якорь. Не надо просить “сделать красиво”. Лучше написать: “пользователь должен понять, что предлагает компания, за 3-5 секунд”. Так задача уже измерима.

В блоке преимуществ фиксируйте не общие слова, а конкретные аргументы. Вместо “высокое качество” напишите “доставка за 24 часа”, “гарантия 12 месяцев”, “поддержка 7 дней в неделю”. Числа помогают. Они не дают блоку превратиться в рекламный туман.

Если на странице есть кейсы, отзывы, логотипы клиентов или сертификаты, перечислите, что именно размещать и в каком виде. Для отзывов важно указать источник: имя, должность, компания, скрин письма или ссылка. Для кейсов — структура: задача, решение, результат. Это снижает риск, что исполнитель соберет блок “на свой вкус”.

Форма заявки тоже требует детализации. Сколько полей, какие обязательные, какой текст на кнопке, что происходит после отправки. Если есть форма на 5 полей, а конверсия падает, редизайн лендинга может начать именно с нее. Иногда 1 лишнее поле стоит дороже, чем кажется.

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

6. Как зафиксировать дизайн- и UX-требования без перегруза ТЗ

Дизайн-часть должна быть точной, но не громоздкой. Если перегрузить ТЗ деталями, фрилансер утонет в правилах и перестанет видеть задачу целиком. Если написать слишком мало, он начнет додумывать. Нужен средний, рабочий уровень конкретики.

Опишите визуальный стиль через 3-5 признаков. Например: минимализм, акцентный цвет, много воздуха, крупная типографика, фото людей, а не абстрактные иллюстрации. Потом приложите 2-4 референса и коротко поясните, что в них подходит под ваш редизайн сайта. Без пояснения референсы превращаются в набор ссылок.

Анимации лучше ограничить списком. Если нужны появление блоков при скролле, плавное раскрытие FAQ или hover-эффекты на кнопках, так и пишите. Если анимации нежелательны из-за скорости или платформы, тоже укажите это. Лендинг не обязан “летать” от анимаций, если они мешают чтению.

UX-требования удобнее описывать через поведение пользователя. Например: на мобильной версии форма должна быть видна после первого экрана, CTA повторяется 2 раза, якорное меню ведет к нужным блокам, текст не перекрывает изображение. Такое описание помогает избежать спорных решений и лишних переделок.

Если у страницы есть ограничения по CMS или шаблону, их стоит назвать прямо. Иногда это Tilda с ограниченным набором блоков, иногда — старый шаблон, где нельзя менять сетку. На этом месте пригодится и внутренняя справка, и [справочный центр ProFreelance](https://profreelance.biz/help.html), если проект идет через площадку и нужно уточнить процесс.

7. Критерии приемки, правки и финальная проверка перед стартом

Критерии приемки лучше писать до начала работ. Тогда не возникнет вопроса, “готово” ли, если кнопка стоит не в том месте. Готовность — это соответствие ТЗ, а не личное впечатление.

Хороший критерий приемки отвечает на 3 вопроса: что сделано, в каком виде и где проверяется. Например: “Макет в Figma содержит все блоки из ТЗ, адаптив подготовлен под 375 и 1440, все тексты согласованы, формы отмечены как рабочие элементы”. Тут уже есть чек и конкретная проверка.

С количеством раундов правок лучше определиться заранее. Если оно не зафиксировано, правки растягиваются бесконечно. Для фрилансера это неудобно, для заказчика — тоже. В ТЗ можно написать: “2 раунда правок после прототипа и 1 раунд после финального макета”.

Перед стартом полезно пройтись по списку согласований. Утверждены ли цель, блоки, тексты, референсы, сроки, формат передачи файлов, кто дает финальный комментарий. Один такой список убирает половину недоразумений. И еще один мелкий, но важный момент: если в проекте участвуют несколько людей, назовите, кто принимает решение.

Если работа идет через площадку, проверьте еще и правила взаимодействия. На profreelance.biz стоит заранее свериться с [правила сайта profreelance.biz. Сайт фриланса. Сайт](https://profreelance.biz/rules.html) и, при необходимости, использовать [безопасная сделка на ProFreelance](https://profreelance.biz/help-safe-deal.html). Это не про формальности ради формальностей. Это про то, чтобы редизайн лендинга не превратился в спор о том, что именно было обещано в переписке.

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