Если показать разработчикам пачку референсов, это не гарантирует, что на выходе заказчик  получит сайт своей мечты. Более того, создание сайта мечты совсем не гарантирует, что пользователи сочтут его удобным, классным и станут туда ходить, как в приложение «Самоката» за хлебом. 

Чтобы точно попасть в ожидания пользователей и закрыть свои бизнес-требования, недостаточно на старте разработки показать команде чужие сайты, которые вам нравятся, и сказать «сделайте так же!». Нужно подробно узнать всё о целевой аудитории, её мотивах, барьерах, а также о ваших конкурентах и бизнеса-задачах, которые хочется закрыть новым сайтом. 

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

Какие шаги проходит каждый проект на этапе агрегации требований у нас в студии и зачем всё это нужно — расскажем ниже.

Агрегация требований — это не просто какая-то аналитика на старте разработки сайта. В заказной разработке это — основа проекта. Именно на этом этапе можно понять:

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

Раньше мы создавали пухлый документ с несколькими вкладками в формате интеллектуальных карт (вроде файлов из сервиса XMind), а сейчас перешли на Figma — и бесконечно довольны этим решением. Так работать проще, удобнее и нагляднее.

Агрегация требований начинается с брифования команды заказчика, на основе которого мы строим следующие этапы аналитики, включающие:

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

1. Видение проекта. Фиксируем параметры проекта: его тип, цели и задачи, а также ожидания всех заинтересованных в проекте лиц.

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

3. CJM (Customer Journey Map). Выделяем целевые сегменты пользователей, продумываем их путь по сайту с учетом ожиданий, запросов и барьеров, а также предлагаем идеи, как преодолеть эти барьеры. 

4. Анализ конкурентов. Смотрим на фишки и факапы на сайтах прямых и косвенных конкурентов, ищем идеи в смежных сферах. 

5. Структура будущего сайта. Формируем структуру сайта на основе предыдущих этапов агрегации. 

6. План развития проекта. Фиксируем классные идеи, которые было бы здорово реализовать в будущем.

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

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

Брифование мы проводим в формате видеозвонка, в котором участвуют: 

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

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

Менеджер проекта со стороны студии. Уточняет техническую сторону: технологии, ограничения, интеграции, «хотелки» заказчика. Чем сложнее проект — тем больше будет вопросов. Например, в e-commerce есть миллиард вопросов по экономике проекта, налогам, логистике, возвратам, интеграциям с внешними системами и т. д. А если планируется сделать маркетплейс — вопросов становится ещё больше.

Аналитик. Четко идет по брифу и подробно расспрашивает заказчика про:

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

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

На этом этапе мы описываем базовые параметры проекта:

• тип — что именно мы будет разрабатывать: например, e-commerce, личный кабинет для корпоративных клиентов, а может — имиджевый сайт;
• стейкхолдеров — лиц, заинтересованных в проекте;
• цели и задачи проекта.

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

Вторая задача при подготовке видения — четко определить цели проекта (и их может быть много!):

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

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

• карту кликов — какие разделы пользуются популярностью у пользователей, а какие нет;
• демографические показатели: пол, возраст, регионы и т. д.;
• запросы, которые приводят пользователей на сайт;
• как сейчас на проекте работает SEO-оптимизация и реклама в целом.

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

Бывает, что заказчики считают какую-то кнопку ОЧЕНЬ ВАЖНОЙ. На деле же оказывается, что пользователи на неё не кликают от слова «совсем». Или наоборот, заказчик хочет избавиться от блока с акциями на главной странице, а карта кликов говорит, что пользователи только туда и жмут. Такие открытия помогают учесть потребности реальных людей при разработке структуры сайта и в дальнейшем при проектировании.

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

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

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

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

Сайты той же тематики, которые подобрали мы. Важно проанализировать конкурентов не только по отрасли, но и по поисковой выдаче, рекламным кампаниям и позициям в популярных маркетплейсах (если товары компании там представлены). Также мы обязательно смотрим зарубежные примеры. Это расширяет картину мира и помогает выявить неочевидные идеи функционала, которые можно использовать на проекте.

Сайты из смежных сфер. Например, если у заказчика сайт по продаже сумок, мы также можем посмотреть крутые проекты в сфере косметики (в том числе — показать уже реализованные свои). А если он производит бакалею, то мы будем изучать проекты в сфере FMCG: от колбасы до кондитерки. Это помогает посмотреть на проект другими глазами и найти фишки, которые можно адаптировать. Например, подсмотреть идею для визуала многослойной упаковки сока, чтобы с ее помощью показать многослойность матраса в карточке товара :)

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

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

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

Если на сайте планируется личный кабинет — на аналитике мы обязательно посмотрим примеры, как его можно реализовать. Часто это задачка со звездочкой, поскольку в B2B-сервисах личные кабинеты закрыты для сторонних пользователей, но нас это не останавливает :)

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

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

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

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

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

Когда вы прошли по всем этапам агрегации требований, вас ждёт следующее:

• Актуализация сметы. Ведь мы работаем по SCRUM и на этапе продажи даем только предварительную (вилочную) оценку. Теперь видение и структура проекта стали четкими, поэтому можно уточнить оценку, а также выделить в смете релизы и спринты. 
• Прототипы ключевых страниц. Всё, что выяснилось на этапе агрегации, ложится в основу прототипов, поскольку полноценно охватывает как бизнес-задачи заказчика, так и потребности пользователей.
• Дизайн главной и внутренних страниц.
• Бэклог или ТЗ, которое потом всё равно превратится в бэклог. 

А дальше — верстка, код и реализация проекта версия за версией. Но всё это — уже совсем другая история :)