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

Согласитесь, клево, когда дизайнер сразу попадает в ваши ожидания. И за время своей многолетней практики я нашел лучшую формулу для этой истории - техническое задание должно состоять из двух частей:

Смысл брифа в том, чтобы понять, что нравится заказчику: выпуклые или плоские кнопки, острые или закругленные углы, одноцветная заливка или с градиентом, яркие или пастельные тона, тонкие или толстые шрифты заголовков, какая цветовая гамма и тд. В общем, описание внешней шкурки будущего сайта.

Примерная схема

Схема нужна, чтобы сразу увидеть объем работы (визуально сразу понимаешь сколько времени займет проект, что можно сразу посоветовать заказчику, что ок, что не ок и тд). Чтобы было понимание, какие блоки будут на страницах. Не все владеют графическими редакторами, поэтому структуру можно накидать даже ручкой на бумаге, потом сфотографировать и прислать. И нам обоим будет легче обсуждать дизайн вашего будущего сайта. Вот примеры:

Вам нужен сайт, но вы сомневаетесь в правильности его структуры и нет уверенности в необходимых блоках на страницах? Ребята сделают прототип сайта - чёткий, грамотный и продуманный, на котором будет видно, где и что расположено, смотрится ли это вместе и будет ли в конце концов работать. Это кропотливая титаническая работа и иногда просто необходимый этап в разработке сайта (например, в случае портала или «тяжёлого» интернет-магазина).

Если в проекте речь о редизайне, и текущая структура сайта устраивает и менять ничего особо не хочется, то и прототип / схема не нужна. Достаточно будет заполненного брифа на стилистику.

Лендинги

Для одностраничных сайтов структура - это текст копирайтера, разбитый на смысловые блоки. Если у вас нет своего копирайтера, постучитесь к Ольге - она напишет клевый продающий текст.

Хотите заказать хорошие информационные тексты или продающие сео-статьи? Нуждаетесь в клевых главных страницах или текстах для лендинга со структурой? Срочно потребовались креативные названия, сочные слоганы или стихотворения? Обращайтесь к девчонкам - помогут! Всё, что вы хотели - не на словах, а на деле!

Эй! Значит, я готовлю подробное ТЗ, а ты тупо разукрашиваешь и все?

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

Я сделаю так, как считаю правильным на основе своего опыта. Если вам не понравится, переделаю по прототипу. Вы ничего не теряете =)

Вот некоторые отзывы от моих заказчиков:

Кстати

Подписывайтесь, жмите колольчик, ставьте лукасы. Ну вы и так все знаете)

Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика - потратил время впустую.

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

Статья будет полезна:

• Всем, кто имеет отношение к созданию сайтов: разработчикам, дизайнерам, верстальщикам.
• Менеджерам проектов.
• Руководителям диджитал-студий.
• Предпринимателям, которые планируют заказать разработку сайта.

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

Что такое техзадание и зачем оно нужно

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

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

Пользы от технического задания много. Для каждой стороны она своя.

Польза для клиента:

• Понять, за что он платит деньги, и каким будет сайт. Можно сразу увидеть структуру, понять, что и как будет работать. Прикинуть, все ли устраивает. Если нет - без проблем поменять еще до начала разработки.
• Увидеть компетентность исполнителя. Если техзадание понятное и четкое - доверие к разработчику повышается. Если там написана каша - возможно, стоит бежать и не оглядываться.
• Застраховаться от недобросовестности исполнителя. Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор - можно даже принудить через суд.
• Упростить замену исполнителей. Если клиент и разработчик повздорили и разбежались, создание сайта может сильно затянуться. Когда есть подробное техзадание, его можно передать новой команде - она втянется в работу в разы быстрее.
• Узнать стоимость разработки сложного продукта. Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции. Для этого и нужно подготовить техзадание.

Польза для исполнителя:

• Понять, что хочет заказчик. Клиенту задают десятки вопросов, показывают примеры, предлагают решения. Затем записывают все в единый документ и согласовывают. Если все окей - ура, вы поняли правильно.
• Застраховаться от внезапных хотелок клиента. Иногда попадаются заказчики, которые хотят поменять задачу на полпути. Если вы согласовали и подписали ТЗ, вам не страшно подобное. В случае чего, даже суд будет на вашей стороне.
• Показать свою компетентность. Классно подготовленное техзадание покажет клиенту экспертность разработчиков. Если компания сомневалась, доверять ли вам разработку сайта, сомнения с большой вероятностью развеются.
• Заработать деньги. Некоторые студии и разработчики предлагают составление ТЗ как отдельную услугу.

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

Теперь давайте разберемся, как составить хорошее техзадание, которое выполняет все эти функции.

Техзадание составляет исполнитель

Вообще техзадание может составить кто угодно. «Нужен сайт-визитка для стоматологической клиники» - это уже техзадание. Но будет ли оно выполнять свои функции? Вряд ли.

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

Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Збс, одобряю». Он тоже должен участвовать в процессе:

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

Пишите однозначно и точно

Этот совет вытекает из главной цели техзадания - «Убедиться, что клиент и исполнитель правильно поняли друг друга».

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

Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:

То же самое - с невнятными формулировками, которые ничего сами по себе не значат:

• Сайт должен понравиться заказчику. А если у него будет плохое настроение?
• Сайт должен быть удобным. Что это значит? Удобным для чего?
• Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
• Качественный экспертный контент. Ну, вы поняли.

Проверяйте, нет ли в тексте неоднозначностей. Если есть - перепишите. Ваши формулировки должны быть четкими и точными:

• Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
• Большие нагрузки → 50 тысяч посетителей одновременно.
• На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
• Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.

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

Укажите общую информацию

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

А еще стоит указать цель сайта и описать его функционал в двух словах - чтобы не получить интернет-магазин вместо блога.

Поясните сложные термины

Первое правило техзадания - оно должно быть понятно всем, для кого предназначено. Если вы собираетесь использовать термины, которые может не понять ваша клиентка - владелица магазина детских игрушек - обязательно поясните их. Понятным языком, а не копипастой из «Википедии».

Опишите инструменты и требования к хостингу

Представьте, что вы 2 месяца делали крутой сайт. Каждый этап согласовывали с клиентом - он в восторге. И вот пришло время сдавать работу. Вы показываете админку, а клиент кричит: «Это что такое? Модэкс?! Я думал, вы сделаете на «Вордпрессе»!»

Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP - а у клиента сервер на.NET.

Перечислите требования к работе сайта

Сайт должен работать во всех браузерах актуальных версий и на всех типах устройств. Да, это очевидно для любого разработчика и любого заказчика. Но лучше написать, чтобы защитить клиента от недобросовестно выполненной работы.

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

Укажите структуру сайта

До начала отрисовки дизайна и верстки вам нужно согласовать с клиентом структуру сайта.

Пообщайтесь с заказчиком, выясните, что ему надо. Соберите разработчиков, сеошников, маркетологов, главреда - и решите, какие страницы нужны на сайте. Подумайте, как они будут связаны между собой, с какой на какую можно перейти.

Можно показать структуру списком, можно нарисовать блок-схему. Как вам удобнее.

Это один из важнейших этапов работы на сайтом. Структура - это фундамент. Если она неудачная - сайт получится кривой.

Объясните, что будет на каждой странице

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

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

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

Распишите сценарии использования сайта

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

• Действие пользователя.
• Ответное действие сайта.
• Результат.

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

Подробнее о сценариях использования читайте в «Википедии ».

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

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

Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «Качественный, интересный и продающий контент, полезный для целевой аудитории». Это мусор, он никому не нужен.

Указать, что весь контент должен быть уникальный, - это полезно. Еще одна защита клиента от недобросовестных исполнителей.

Опишите дизайн (если сможете)

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

Писать про красивый и современный дизайн не надо. Это ничего не значит, не имеет силы и вообще фу.

Вместо вывода: структура техзадания

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

• Информация о компании и целевой аудитории, цели и задачи сайта.
• Глоссарий терминов, которые могут быть непонятны клиенту.
• Технические требования к верстке и работе сайта.
• Описание используемых технологий и список требований к хостингу.
• Подробная структура сайта.
• Прототипы страниц или описания элементов, которые должны на них быть.
• Сценарии использования нестандартного интерфейса (опционально).
• Список контента, который делает разработчик.
• Требования к дизайну (опционально).

• Правила составления Software Requirements Specification. SRS - следующая ступень эволюции техзадания. Нужна для больших и сложных проектов.
• Стандарты и шаблоны ТЗ на разработку ПО. Описания разных ГОСТов и методологий создания технических заданий.

Это конец той части, которую писал я. Но есть и другая - комментарии специалистов, которые помогали делать гайд. Почитайте, это тоже интересно.

Комментарии разработчиков

Я пообщался с несколькими разработчиками, чтобы узнать, как они составляют техзадания. Передаю микрофон им.

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

ТЗ составляет менеджер проекта после общения с клиентом и обсуждения задачи с дизайнером.

Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.

Мы указываем:

• Информацию о компании и цель сайта.
• Требования к дизайну, цветовую гамму.
• Используемые технологии и CMS.
• Кто занимается контентом - мы или клиент.
• Структуру сайта вплоть до каждой страницы.
• Описания каждой страницы. Мы не делаем прототипы, но указываем, какие элементы должны быть на странице, и как они должны работать.

Последние 2 раздела - самые важные. Именно они обеспечивают понимание, какие будет сайт и как он будет работать.

Очень важный момент - нельзя просто отдать техзадание разработчикам и надеяться, что они все сделают хорошо. ТЗ - это список требований к сайту, оно не может заменить общение. Важно убедиться, что каждый член команды понимает общую цель, а не просто выполняет задачи на потоке. Если что-то непонятно - надо объяснить, обсудить, дать подробные комментарии.

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

Человеку, не имевшему ранее дела с созданием лендинга, написать техническое задание порой кажется невыполнимой задачей. Возникает множество вопросов. А что писать? Какую информацию указать приоритетной? Как сделать все так, чтобы результат не пришлось переделывать по сто раз, расходуя бюджет?

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

В качестве примера приведены скриншоты одностраничника для бизнес-центра 7One, разработанного нашей командой. Подробный кейс о здании можно прочитать .

Цели лендинга

Покупка билетов на мероприятие

Продажа определенного товара или категории товаров

Продажа конкретной услуги (например, модельная стрижка собак, доставка цветов и т.п)

Презентация нового продукта или софта (например, iPhone XS)

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

Хорошая система планирования - технология SMART. Согласно этой концепции, большинство целей должны быть:

• Конкретными
• Измеримыми
• Достижимыми
• Значимыми
• Ограниченными по времени.

Пример такой цели:

Получить не менее 1000 заказов на доставку букетов с сайта за первые две недели после запуска. Сумма среднего чека должна быть не меньше 3000 рублей.

Не обязательно ставить только такие цели. Оптимальное соотношение 80 % к 20 %. Для начала сядьте и выпишите по пунктам, чего вы хотите от будущего сайта.

Определение целевой аудитории

Кто ваш клиент? Какие пользователи, открыв ваш лендинг, захотят на нем задержаться, а не закроют страницу в то же мгновение? Определение вашей аудитории - очень важный этап, которым часто пренебрегают.

Подумайте:

• Какого возраста и пола моя аудитория?
• Кто мои клиенты по роду деятельности? (учащиеся, студенты, домохозяйки, рабочие, бизнесмены и т.д.)
• Какие проблемы их волнуют?
• Как мой продукт может решить эти проблемы?

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

Пример: потенциальные клиенты бизнес-центра «7ONE» - владельцы бизнеса, подыскивающие комфортный офис для аренды на Севере Москвы. Условия аренды помещений в бизнес-центре, прописанные на одном из экранов лендинга, соответствуют потребностям потребителей.

Чем меньше степень вовлеченности пользователя, тем больше информации ему нужно предоставить. Что подводит нас к следующему пункту.

Основные конкуренты

Есть ли уже ваш продукт на рынке? Назовите основных конкурентов и приложите ссылки на их сайты.

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

Посмотрите 5-6 лендингов вашей тематики. Если у вас продукт, которого нет на рынке, изучите максимально близкие по теме сайты. Выпишите себе что вам в них понравилось, а что показалось лишним. Подумайте, какие фишки можно преобразовать и включить в ТЗ.

При этом вовсе необязательно делать таймер обратного отсчёта, если даже у всех представителей ниши он есть. Возможно на самом деле это только отталкивает посетителей. Увы, проверить конверсию каждого ресурса без доступа к аналитике не получится. Остаётся только выдвигать гипотезы на основе полученных данных.

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

Описание продукта или услуги

Чтобы разработчикам лучше понять ваш продукт, расскажите о нем. Приложите все открытые документы: инструкции по применению, описания на иностранном языке (если продукт импортный). Если вы продаете билет на мероприятие или курс, обязательно прикрепляйте к техническому заданию расписание, план занятий и прочие материалы.

Кроме того, при написании текста лендинга копирайтер также будет опираться на эти данные.

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

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

Давайте определимся с концепцией и структурой сайта и на основании вашего видения проблем целевой аудитории составим ТЗ на разработку дизайна одностраничника

Подавляющее большинство студий ориентировано на средние бюджеты и работает по упрощенной схеме. Техническое задание составляет сам заказчик без помощи исполнителя, а над проектом обычно работает два человека – менеджер и дизайнер, который совмещает обязанности юзабилитиста. Макет разрабатывается сразу, без прототипа. При такой схеме работы очень многое зависит от заказчика – от его понимания психологии посетителей и умения излагать свои мысли на языке, понятному для дизайнера. Если вы попали в похожую ситуацию, главное – правильно составить ТЗ на разработку дизайна одностраничного сайта.

Что должно содержать ТЗ на разработку дизайна одностраничного сайта

Ваша задача – не просто как можно детальнее описать требования к дизайну, но сделать документ четким, структурированным и понятным. Очень важно использовать маркировку пунктов, чтоб при дальнейшем обсуждении ТЗ на разработку дизайна одностраничного сайта любая из сторон могла просто ссылаться, например, на пункт “4 B”, а не объяснять, что речь идет о моменте, описанном на 3-й странице во втором абзаце снизу.

Заказать техническое задание от 500 руб

Итак, базовое ТЗ на разработку дизайна одностраничного сайта должно содержать:

• 1. Общее описание одностраничного сайта

  Каковы цели сайта, кто является его целевой аудиторией? Какие ощущения он должен вызывать у посетителей – доверие, радость, солидность, оригинальность и т.д. С чем должен ассоциироваться? Должен ли запоминаться? Иными словами, в этом пункте нужно сосредоточить внимание на эмоциональных характеристиках будущего дизайна. Не советую сводить этот пункт до описания типа «Красивый дизайн, который должен вызывать позитивные эмоции». Поверьте, понятие красоты и позитива у вас и у дизайнера может очень сильно отличаться.

• 2. Структура сайта в виде схемы

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

• 3. Общие пожелания по дизайну:

  • варианты предпочтений по цветовой гамме, желательно с примерами, которые можно генерировать с помощью сервиса Colorscheme.ru;
  • размер сайта (резиновый, фиксированный, мультиразмерный) и разрешение, под которое его нужно будет адаптировать;
  • базовая структура страницы: количество колонок, наличие шапки и футера и других сквозных элементов;
  • другие пожелания, которые касаются конкретных моментов внешнего вида одностраничного сайта.

• 4. Описание сквозных блоков

  Практически у всех одностраничных сайтов есть, как минимум, три сквозных блока, в которых контент одинаковый – шапка, футер и меню. Чтоб не описывать эти блоки, можно вынести их в единый пункт.

  • Шапка : каково ее целевое назначение? Должна привлекать к себе внимание, или наоборот – не бросаться в глаза? Какие инфоблоки должны там размещаться? и т.д.
  • Футер – аналогично шапке. Назначение, содержание, акценты.
  • Описание меню должно содержать перечень ссылок (или блоков ссылок) в порядке иерархии. При необходимости нужно уточнить, на каких пунктах должно акцентироваться внимание и какие есть пожелания по оформлению и подсветке ссылок.

• 5. Описание блоков (экранов) одностраничного сайта

  Описание каждого блока должно включать:

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

• 6. Описание отдельных графических элементов

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

http://xn--80ahnerbbccukm3exc.xn--80aswg/wp-content/uploads/2017/05/Зачем-вам-простой-и-удобный.jpg 360 950 Одностраничник http://xn--80ahnerbbccukm3exc.xn--80aswg/wp-content/uploads/2018/01/hand.png Одностраничник 2017-05-25 10:34:57