В заказной разработке обычно мы концентрируемся на той части CJM, которая касается взаимодействия пользователя с сайтом. И рассматриваем лишь самые важные маршруты для самых частых персон. В такой форме это оправданно и позволяет улучшать пользовательский опыт в программном продукте.
Итак. CJM инструмент для анализа пользовательского опыта на каждом шаге и точке контакта при взаимодействии пользователя с брендом. Инструмент неплох для заказной разработки или для анализа готового программного продукта. В продуктовой разработке лучше использовать фреймворк RAT+JTBD (об этих аббревиатурах в параграфах 4.3.3 и 4.3.7). Важно найти баланс между трудоемкостью и практичностью. А еще CJM любят вставлять в красивые презентации. Если это произошло значит, CJM уже мертв.
4.2.5. Решения
Аналитика никому не нужна.
Нужны выводы из аналитики.
Итак. Мы определились с сегментами. Описали целевые персоны. Выявили их боли и мотивы.
Все это было проделано, чтобы понять, какие вещи (функции, разделы, экраны) мы должны предусмотреть в будущем проекте для того, чтобы эти боли закрыть.
Какими должны быть предложенные решения?
В первую очередь, не случайными, а закрывающими выявленные выше потребности персоны. Например: мы делаем отзывы со ссылками на соцсети не просто так, а потому что выяснили, что наш персонаж Леночка не решается покупать косметику без отзывов, но не так наивна, чтобы верить анонимным отзывам на сайте интернет-магазина.
Важно, чтобы решения отвечали уровню проекта. Если заказчик хочет простой корпоративный сайт, можно предложить интеграцию с чем-то диковинным, калькулятор с 3D-моделями. Но аккуратно, с оговоркой, что это идея на развитие. Иначе у заказчика останется неприятный осадок, что его не слышат либо пытаются развести на дополнительные опции.
Как правило, мы описываем предлагаемые решения сначала рядом с каждым аватаром, чтобы четко прослеживалась связь решений, болей и мотивов. Для каждой персоны решения размечаем цветными рамками (цветовое кодирование: одна персона один цвет). Используем иконки для разметки этапов, акцентов или вопросов, которые нужно разобрать.
И ниже, в этой же вкладке Агрегации требований делаем сводную таблицу всех функций, также размеченную цветами. Не только чтобы было легче воспринять будущий проект, но и чтобы можно было отследить источник боли то, ради чего эта функция была придумана. Пока не увлекаемся структурированием. На этом этапе нам важен сам список. Компоновать по разделам и продумывать перелинковки будем чуть позднее.
Описывайте решения достаточно подробно, чтобы было ясно, в чем фишка и как она будет работать на решение боли.
Итак. Из болей и мотивов следуют решения (но ими не ограничиваются). Предложите решение на каждую боль. И далее сведите все решения в общий список.
4.2.6. Анализ сайтов конкурентов
Кто знает врага и знает себя, не окажется в опасности и в ста сражениях. Тот, кто не знает врага, но знает себя, будет то побеждать, то проигрывать. Тот, кто не знает ни врага, ни себя, неизбежно будет разбит в каждом сражении.
Сунь-Цзы. Искусство войныНам нужно посмотреть и изучить проекты конкурентов, чтобы понять:
1. что у них есть прикольного, что имело бы смысл сделать у себя;
2. в чем у них есть лажа, и каких ошибок следует избегать.
Тут важно отметить и для себя, и для заказчика, что это не анализ рынка с попыткой разобраться, кто и почему зарабатывает на этом рынке больше, и не анализ маркетинговых кампаний мы смотрим на конкуренцию только с позиции сайтов/мобильных приложений. Выявляем позитивные и негативные тренды, отмечаем особо интересные фишки.
Первое, что нужно рассмотреть проекты, на которые сослался сам заказчик. В большинстве случаев заказчик знает конкурентов. Однако с тем же успехом имеет ряд галлюцинаций по этому вопросу. Вот ТОП-3:
1. «У нас нет конкурентов». Не верьте. Либо что-то не договаривает, либо что-то не понимает. Логика там примерно такая: «Мы делаем Инстаграм для котиков со встроенным маркетплейсом. Ни у кого больше нет Инстаграма для котов со встроенным маркетплейсом. Поэтому у нас нет конкурентов!» Логично? Хоть глупо, но логично! Посмотрите, как люди решают ту же самую проблему, которую решает компания-заказчик.
2. «Наши главные конкуренты-враги компания Копыта и Рога с соседней улицы! Они даже логотип сделали почти как у нас. С рогами и копытами». Это обычно высказывается на эмоциях. Заказчика очень бесит какой-то местный, локальный конкурент. И он считает его главным врагом. На самом деле, в интернете он будет конкурировать с какой-нибудь Икеей, Wildberries или Озоном. Но думать про это бздляво. А вот «Копыта и Рога» с соседней улицы в самый раз.
2. «Наши главные конкуренты-враги компания Копыта и Рога с соседней улицы! Они даже логотип сделали почти как у нас. С рогами и копытами». Это обычно высказывается на эмоциях. Заказчика очень бесит какой-то местный, локальный конкурент. И он считает его главным врагом. На самом деле, в интернете он будет конкурировать с какой-нибудь Икеей, Wildberries или Озоном. Но думать про это бздляво. А вот «Копыта и Рога» с соседней улицы в самый раз.
Анализируйте не только конкурентов по отрасли, но и по поисковой выдаче, и по рекламным кампаниям, и по позициям в популярных маркетплейсах. Смотрите и прямую, и косвенную конкуренцию.
3. «Все сайты наших конкурентов ужас и кошмар. Там нечего смотреть». Редко, но бывает. Особенно в B2B. Тогда стоит посмотреть смежные отрасли:
a. Как аналогичные вещи решаются на зарубежных сайтах?
b. Какая отрасль похожа на эту? Есть ли там сильные игроки? Как выглядят их решения?
По реальным конкурентам мы смотрим как плюсы, так и минусы. Но минусами не нужно увлекаться, описывая каждую опечатку. Только значимые для процесса продажи ошибки.
Описывая плюсы и минусы, не забывайте маркировать их иконками, иллюстрировать картинками и, главное, понятно рассказывайте, в чем суть фишки или ошибки, как это влияет на продажи, стоит ли повторять решения и в каком виде.
Если же среди реальных конкурентов что ни сайт, то ужас и кошмар, разработанный на заре интернета (а в некоторых отраслях до сих пор такое случается), то не тратьте время на подробный разбор дайте общее заключение.
Дополнительно можно рассмотреть сайты в смежных тематиках. Например, если ваш проект про доставку пиццы, сайты по доставке роллов также могут быть источником хороших идей.
В зарубежном сегменте, в идеале, нужно смотреть ту же сферу, что и ваш проект, но если там ничего примечательного нет, то смотрите просто хоть сколько-нибудь релевантные теме крутые сайты, предлагайте фишки.
4.2.7. Семантическое ядро (опционально)
Дополнительно вы можете проанализировать, по каким запросам пользователи ищут решения своих проблем. Я считаю, что на этом этапе такой анализ несколько избыточен, так как касается, скорее, не структуры проекта, а его контентной части. Нас интересуют функции с точки зрения программного кода, а не конкретный перечень товаров в каталоге. Более того, пока проект в разработке, ситуация десять раз поменяется. Однако, если ресурсы проекта, бюджеты и компетенции позволяют (а там добавляется 2040 часов работы) можно собрать предварительное, базовое семантическое ядро и посмотреть, нужно ли предусматривать в структуре проекта какие-то функции.
Существует множество сервисов автоматического сбора семантических ядер вроде Key Collector. Проще всего собрать запросы вручную с помощью онлайн-сервиса Яндекса Wordstat. Фиксируйте не только текст запроса, но и число обращений к нему.
Наша задача на этом этапе понять и показать значимость ключевых страниц и перечень основных запросов, по которым на эти страницы может идти трафик.
Для некоторых интересных, но недостаточно раскрытых в структуре запросов по тематике проекта можно рекомендовать создание отдельных посадочных страниц. Примерно так:
4.2.8. Структура будущего продукта
Кульминация процесса, то, ради чего делались все предыдущие вкладки составление оптимальной структуры проекта. Оптимальной значит в ней будут все необходимые страницы и функции для решения поставленных задач и закрытия болей аудитории, но не будет лишних.
Не стесняйтесь отговаривать от реализации очевидно избыточного функционала, который мог попасть в смету по историческим причинам или как хотелка заказчика. Если на сайте три страницы, и все они сплошь картинки, то поиск ни к чему. Заказчик оценит, что вы не только предлагаете функционал, что приводит к росту бюджета и сроков, но и советуете пути оптимизации, что, наоборот, экономит его деньги.
Мы описываем структуру достаточно подробно. Не только перечень страниц или блоков на страницах. Вплоть до состава этих блоков: заголовков, подзаголовков. Часто это помогает составить карту контента. Кроме того, по такой структуре потом очень просто сделать смету, бэклоги или контролировать состав элементов на прототипах и дизайне.
Описывая структуру страницы, не забывайте подбирать примеры для сложных и важных элементов. Это могут быть текстовые примеры например, возможный слоган или перечень преимуществ и примеры визуальные. Картинка особенно важна, когда показываешь какую-то визуальную фишку, например, в промо-блоке. Оформляйте так: