Почему мы не используем брифы и жёсткое ТЗ на сайт

Почему мы не используем брифы и жёсткое ТЗ для разработки сайта

Перед разработкой сайта заказчику часто предлагают заполнить бриф.

Название компании. Целевая аудитория. Конкуренты. Предпочитаемые цвета. Какие страницы нужны. Какие сайты нравятся. Какие не нравятся. Прикрепите логотип. Опишите пожелания.

Мы сознательно отказались от такого подхода.

Не потому, что требования к сайту не нужны. И не потому, что мы начинаем проекты без структуры и договорённостей.

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

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

Поэтому первым этапом разработки у нас становится интервью.

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

{здесь вставить изображение: «Бриф → ответы на вопросы» против «Интервью → понимание бизнеса → требования → концепт»}

Весь процесс разработки — от первого разговора до production — мы отдельно описали в статье «Как мы работаем над сайтом: от интервью до запуска».
{ссылка на /blog/kak-my-rabotaem-nad-sajtom}

Проблема не в самом брифе, а в том, что он пытается заменить разговор

Бриф может быть удобным способом собрать базовые сведения.

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

Представим вопрос:

«Кто ваша целевая аудитория?»

Заказчик может написать:

«Мужчины и женщины 25–50 лет, средний и высокий доход».

Формально поле заполнено.

Практически для проектирования сайта мы почти ничего не узнали.

Нам важнее понять другое.

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

У одного бизнеса за короткой формулировкой «наша ЦА — компании» могут скрываться собственник, директор по развитию, маркетолог и руководитель отдела продаж.

У каждого — свои цели, аргументы и вопросы.

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

А интервью позволяет двигаться за ответами.

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

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

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

Так разговор постепенно превращается из сбора формальных данных в исследование бизнеса.

Мы не хотим заставлять клиента делать нашу работу за нас

Есть ещё одна причина.

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

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

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

Это нормально.

Если собственник уже самостоятельно определил:

• все страницы;
• последовательность блоков;
• CTA;
• пользовательские сценарии;
• интеграции;
• логику интерфейса;
• техническую реализацию,

то возникает вопрос, зачем ему вообще студия с экспертизой.

Поэтому мы предпочитаем другую модель.

Заказчик рассказывает нам о бизнесе.

Мы задаём вопросы и переводим полученные знания в решение.

То есть не просим клиента заранее спроектировать сайт за нас.

Самый важный человек на интервью — ЛПР

В обсуждении проекта могут участвовать разные сотрудники.

Маркетолог знает текущие каналы привлечения.

Отдел продаж — реальные вопросы клиентов.

Технический специалист — ограничения существующей инфраструктуры.

Руководитель направления — особенности продукта.

Все эти знания полезны.

Но ключевые этапы проекта мы всё равно стараемся обсуждать непосредственно с собственником или другим ЛПР.

Причина практическая.

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

Он же в конечном счёте принимает решения.

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

Мы просто разговаривали не с тем человеком.

Поэтому со стороны заказчика на интервью могут присутствовать все заинтересованные сотрудники, но ключевые выводы и решения мы стараемся презентовать ЛПР лично.

О чём мы спрашиваем вместо вопросов «какой цвет вам нравится»

Продолжительность исследовательского этапа зависит от бизнеса и самого проекта.

Где-то основные вводные удаётся собрать за несколько встреч. Где-то погружение занимает значительно больше времени.

Универсального сценария нет именно потому, что компании разные.

Но есть несколько вещей, которые мы обязательно хотим понять до начала проектирования.

Что за продукт перед нами

Что именно покупает клиент?

Не юридическое название услуги, а реальный результат.

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

Если мы этого не понимаем, проектировать коммуникацию бессмысленно.

Кто покупает продукт

Не только демографическое описание аудитории.

Нам важно восстановить логику человека.

Почему он начинает искать решение?

Почему может отказаться?

Какие альтернативы рассматривает?

Какая информация помогает ему принять решение?

Какие сомнения нужно снять ещё до заявки?

Почему выбирают именно эту компанию

Если два бизнеса предлагают визуально похожий продукт, где возникает реальное отличие?

В цене?

Сервисе?

Компетенции?

Скорости?

Условиях работы?

Репутации?

Определённой специализации?

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

Как устроены продажи

Что происходит после заявки?

Кто её получает?

Где она хранится?

Есть ли CRM?

Кто связывается с клиентом?

Как долго длится цикл сделки?

Какая информация нужна менеджеру?

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

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

Мы можем обсудить CRM или другой способ упростить процесс.

Это не означает, что мы обязательно станем что-то внедрять.

Иногда после обсуждения оказывается, что существующего Excel компании пока действительно достаточно.

И это тоже нормальный результат.

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

Мы анализируем не только слова заказчика

Интервью — основной источник контекста, но не единственный.

Параллельно мы изучаем рынок практически.

Смотрим сайты конкурентов.

Изучаем их структуру и CTA.

Смотрим поисковую выдачу и ключевые запросы через Яндекс Вордстат.

Изучаем отзывы о самом заказчике и его конкурентах.

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

Пытаемся понять, какие паттерны повторяются в нише и где могут находиться слабые места.

Отдельно сегментируем аудиторию, если это ещё не сделал сам бизнес.

Причём сегменты не всегда отличаются возрастом или доходом.

Один и тот же товар люди могут покупать для совершенно разных сценариев.

Например, условный надувной матрас одному нужен для отдыха на море, а другому — как дополнительное спальное место дома.

Товар тот же.

Мотивация, контекст покупки, аргументы и нужная информация — разные.

Для проектирования сайта это существеннее, чем строка «мужчины и женщины 25–45 лет».

{здесь вставить изображение: пример сегментации одной аудитории по разным сценариям покупки}

А если мы поняли бизнес неправильно?

Такое бывает.

Можно провести интервью, посмотреть конкурентов, собрать информацию и всё равно сделать неправильный вывод.

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

Если собственник говорит:

«Нет, наши клиенты ведут себя не так»

— мы разбираемся почему.

Иногда после дополнительных вопросов оказывается, что первоначальная гипотеза всё-таки полезна.

А иногда — что мы действительно неправильно поняли ситуацию.

У нас были разговоры, когда заказчик буквально останавливал объяснение словами:

«Нет, вы не так поняли».

И он был прав.

Это нормальная часть погружения.

Задача интервью не в том, чтобы студия один раз собрала информацию и дальше считала свою интерпретацию истиной.

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

Здесь проходит важная граница нашей экспертизы.

Бизнес заказчика лучше знает заказчик.

Как превратить его знания в работающий сайт — уже наша ответственность.

Поэтому после интервью начинается следующий этап: проектирование концепции и защита конкретных UX-решений.

Подробнее об этом — «Как мы принимаем и защищаем решения в дизайне сайта».
{ссылка на /blog/kak-my-prinimaem-i-zashchishchaem-resheniya-v-dizajne-sajta}

Значит ли это, что мы вообще не работаем с ТЗ?

Нет.

Важно разделить две вещи:

ТЗ как источник требований

и

ТЗ как абсолютную инструкцию, от которой запрещено отступать.

Первое может быть полезно.

Второе подходит далеко не каждому проекту.

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

Мы можем работать и в таком режиме.

Но типичный коммерческий проект у малого или среднего бизнеса устроен иначе.

Нередко заказчик ещё сам не знает окончательно, какое решение ему нужно. Именно поэтому он обращается к специалистам.

Иногда техническое задание оказывается составлено слишком широко.

Иногда требования завышены.

Иногда занижены.

Иногда разные пункты противоречат друг другу.

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

Следовать такому документу буквально только потому, что он называется «ТЗ», для нас странно.

Если требование вызывает вопросы, его нужно обсуждать.

Хорошее ТЗ не заменяет понимание задачи

Представим, что в документе написано:

«Сайт должен иметь личный кабинет».

Технически требование понятно.

Но для нормального проектирования этого недостаточно.

Кто будет пользоваться личным кабинетом?

Зачем?

Что человек должен там делать?

Как часто?

Какие данные видеть?

Откуда эти данные будут поступать?

Что произойдёт, если вообще убрать личный кабинет?

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

А возможно, задача решается в десять раз проще.

Поэтому даже подробная спецификация не отменяет вопрос:

«Зачем?»

Для нас ТЗ может быть хорошей опорой в разговоре.

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

Сначала обсуждаем его с заказчиком.

Почему жёсткое ТЗ особенно опасно, когда сам заказчик ещё ищет решение

В начале проекта часть решений существует только как гипотеза.

Компания может думать, что ей нужен лендинг.

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

Заказчик может считать, что достаточно отправлять заявки на почту.

В разговоре выясняется, что отдел продаж уже работает в CRM.

Или наоборот: мы можем предложить интеграцию, а собственник объяснит, что при текущем объёме обращений она просто не окупится.

Если всё это заранее зафиксировать как неизменяемую инструкцию, проект лишается пространства для нормального проектирования.

Получается странная ситуация:

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

Мы не считаем изменения требований чем-то неправильным сами по себе.

Проблема возникает, когда изменение уже утверждённого scope пытаются представить как небольшую бесплатную правку.

Эту границу подробно разбираем в статье «Правки при разработке сайта: почему мы не просто делаем всё, что просит заказчик».
{ссылка на /blog/pravki-pri-razrabotke-sajta}

Но без документов ведь всё можно забыть

Можно.

Поэтому отказ от универсального брифа не означает отказ от фиксации информации.

Наоборот, разговоры по проекту мы стараемся сохранять системно.

Для встреч используем AI-summary: после обсуждения остаётся конспект, в том числе развёрнутый.

Материалы хранятся в папке проекта и при необходимости доступны заказчику.

Это решает сразу несколько задач.

Не нужно рассчитывать на память участников.

Можно вернуться к аргументам, которые звучали несколько недель назад.

Новый участник проекта может быстрее восстановить контекст.

А при спорной ситуации можно посмотреть, как именно формулировалась первоначальная договорённость.

Мы не стремимся документировать каждую реплику ради бюрократии.

Задача другая — не потерять важный контекст по мере развития проекта.

После интервью появляется не документ ради документа, а концепция

Исследование должно во что-то превращаться.

В нашем процессе следующим этапом становится чёрно-белый прототип.

В нём уже появляются:

• структура;
• секции;
• CTA;
• пользовательские сценарии;
• логика взаимодействия;
• CJM для разных сегментов аудитории.

То есть знания о бизнесе превращаются в конкретное решение.

И вот его уже можно обсуждать предметно.

Не:

«Какой сайт вы хотите?»

А:

«Мы поставили этот блок здесь, потому что для этого сегмента сначала нужно закрыть такое-то возражение».

Не:

«Как должна выглядеть главная страница?»

А:

«Вот сценарий человека от входа на сайт до целевого действия».

Так разговор постепенно переходит из области абстрактных пожеланий в область аргументированных решений.

Именно поэтому мы сначала разговариваем, потом проектируем и только затем переходим к визуальному дизайну.

Это не процесс без правил

Со стороны отказ от брифов и жёсткого ТЗ иногда можно ошибочно понять как:

«Просто поговорим, а дальше что-нибудь сделаем».

Нет.

У проекта по-прежнему есть:

• бизнес-требования;
• согласованные этапы;
• договор;
• объём работ;
• фиксация встреч;
• промежуточные согласования;
• контроль изменений;
• тестирование;
• точка приёмки.

Мы отказываемся не от структуры.

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

Это разные вещи.

И чем сложнее продукт, тем существеннее эта разница.

Почему этот подход требует больше ответственности и от студии

Есть и обратная сторона.

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

Нельзя получить фразу «мы работаем с юридическими лицами» и на этом закончить исследование.

Нужно разбираться дальше.

Кто именно принимает решение?

Что для него важно?

Как устроены продажи?

Что говорят существующие клиенты?

Почему покупают?

Почему отказываются?

Какие альтернативы рассматривают?

Что происходит после заявки?

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

Для нас это правильный обмен.

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

В конечном счёте нам нужен не бриф, а понимание

Сайт можно сделать строго по документу и формально выполнить каждое требование.

Но само по себе это ещё не означает, что бизнес получил хорошее решение.

Поэтому перед первым прототипом нам важнее понимать:

что продаёт компания;

кому;

почему люди покупают;

что мешает им принять решение;

как устроен путь от первого контакта до продажи;

и какую роль во всём этом должен играть сайт.

После этого уже имеет смысл обсуждать страницы, блоки, интеграции и интерфейсы.

Именно поэтому мы начинаем не с просьбы:

«Заполните наш бриф».

А с предложения:

«Расскажите, как работает ваш бизнес».

Дальше наша задача — задавать вопросы.

Что в итоге покупает заказчик

Такой процесс связан с более общей моделью нашей работы.

Клиент приходит не только за технически исправным сайтом.

Он привлекает команду, которая должна понять задачу, предложить решение, объяснить его и затем реализовать.

Поэтому ценность студии для нас не измеряется количеством заполненных документов или числом отрисованных экранов.

Она находится в качестве решений, которые появляются из понимания бизнеса.

Подробнее об этом — «Что на самом деле покупает бизнес, заказывая сайт у студии».
{ссылка на /blog/chto-pokupaet-biznes-zakazyvaya-sajt-u-studii}

А после реализации эти решения ещё нужно проверить в реальной работе интерфейса. Как именно мы проверяем адаптивность, формы, интеграции и пользовательские сценарии, разбираем в статье «Как мы тестируем сайт перед запуском».
{ссылка на /blog/kak-my-testiruem-sajt-pered-zapuskom}

Есть задача по сайту? Не готовьте для нас тридцатистраничный бриф

Если у вас уже есть техническое задание — присылайте. Мы изучим его и используем как источник контекста.

Если ТЗ нет — специально составлять его перед первым разговором необязательно.

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

Вам не нужно заранее знать, сколько должно быть страниц, где расположить CTA и какие технологии использовать.

Для этого вы и привлекаете студию.

{здесь вставить CTA}

Начнём с разговора о вашем бизнесе

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

[Записаться на интервью]