How to сделать анализ фичи конкурента за 3 дня – кейс UXSSR
У конкурента вышла новая фича (продукт, функция, услуга, да что угодно). Как понять, нужно ли на нее отреагировать, и как сделать это быстро? Наш клиент столкнулся именно с таким вопросом, и мы знаем, как на него ответить.
Рассказываем "how to" процесса исследования по следам проекта команды UXSSR для одной очень классной компании, которая пожелала остаться неизвестной.
Зачем исследовать новую функцию конкурента?
- Чтобы держать руку на пульсе и быть в курсе тенденций рынка.
- Чтобы понять, что делать – повторять за конкурентом или держаться своего курса.
- Чтобы сэкономить время и ресурсы – лучше потратить 3 дня на изучение фичи, чем начать разрабатывать продукт и наткнуться на подводные камни.
Кто этим должен заниматься?
Есть несколько вариантов:
- продакт менеджер, если у него есть соответствующие скиллы и время;
- отдельный человек в команде, который отвечает за UX-аналитику;
- внешний подрядчик – агентство с большим опытом в исследованиях.
Анализ новых продуктов конкурентов и их функциональности могут делать продакты или другие люди внутри компании. Но часто бывает, что новая фича выходит в неудобное для команды время. Завал по работе, у продактов нет времени, чтобы этим заняться, или не хватает инструментов UX-аналитики. В таком случае можно отдать эту задачу на аутсорс и привлечь внешнего подрядчика с опытом, как было в нашем случае.
Как подступиться к задаче?
Вы обсудили новую фичу внутри команды и решили, что нужно ее исследовать перед тем как делать свою. Что дальше? Как понять, что и как искать, где добывать информацию и что с ней делать в итоге? Мы составили схему из основных шагов, которые помогут ответить на эти вопросы.
Первый этап – Подготовка
Мы выделили основные вопросы, на которые нужно получить ответы, чтобы проанализировать новую фичу конкурента:
- Что это за фича/продукт, как она работает?
- Какая стратегия? Как сама компания позиционирует новый продукт?
- Job для пользователя. Какую проблему пользователя решает с точки зрения теории работ?
- Какая монетизация и экономика?
- Job для продавца. Какие выгоды приносит бизнесу?
- Какие прямые и косвенные конкуренты?
- Как рекламируют этот продукт? На что делают упор?
Это основной, но не исчерпывающий список вопросов, вы можете его дополнять в зависимости от специфики проекта. После того, как стало понятно, какая информация нужна, можно переходить к исследовательской части.
Второй этап – Desk Research
После того, как сформулировали основные вопросы, переходим к исследованию. Мы провели desk research, или как его еще называют "кабинетное исследование", по нескольким направлениям:
- Как компания анонсирует продукт?
- Что об этом пишут тематические ресурсы?
- Какие комментарии оставляют пользователи?
- Как рекламируют продукт? На что делают упор в маркетинговых коммуникациях? (об этом подробнее в конце)
Где искать эту информацию? Мы изучали открытые источники по всему интернету.
Третий этап – UX-исследование
На третьем этапе мы решили узнать опыт пользователя этого продукта и зафиксировать его. Есть несколько способов узнать, как будет выглядеть “user flow” использования продукта. Если продукт уже вышел на рынок и им можно воспользоваться:
- Проводим Usability Test с пользователем (как минимум коридорный).
- Примеряем роль пользователя и проходим путь самостоятельно: скачиваем обновление, пробуем выполнить задачу, смотрим на продукт экспертным взглядом.
А что делать, если продукт еще не запущен? Как понять, как он будет работать для пользователя? Мы придумали такое решение:
- Найти презентационные материалы, где показывают экраны будущего решения.
- Составить из них User Flow, который покажет, каким маршрутом нужно двигаться пользователю, чтобы достичь своей цели.
Четвертый этап – Jobs для основных пользователей
Jobs-To-Be-Done (JTBD) или теория работ— это набор принципов проектирования, позволяющий сместить мышление с "Давайте сделаем такую же фичу" к "Какую задачу/боль/проблему пользователя мы решим?". Мы проанализировали фичу конкурента с точки зрения теории работ и показали 3 основных параметра:
- выгода, которую получает пользователь от использования сервиса;
- боли, которые существуют у пользователя с этой задачей сейчас;
- Jobs или задачи, которые пользователь хочет решить.
Работа с канвасом Value Proposition помогла понять, какие задачи пытается решить человек с помощью продукта, какие при этом возникают сложности, и что принесет наибольшую выгоду в ходе использования.
Пятый этап – Маркетинговая коммуникация
Последний этап – проанализировать, как компания рассказывает про свой продукт в СМИ, какие плюсы для пользователей подсвечивает. Яндекс.Драйв, например, говорил о новом тарифе, как о революции. Главный посыл всех сообщений в медиапространстве был: "Цена известна заранее". Можно предположить, что именно эту боль пользователей новая фича должна закрыть. Мы же можем исследовать, есть ли и у наших пользователей такая проблема и нужно ли ее решать.
Вместо заключения
Итак, если пройтись по всем 5 пунктам, то можно собрать целостное представление о том, что делает ваш конкурент, как это работает, кому это нужно и главное, зачем. После этого вам будет легко решить, нужно ли делать такую фичу у себя или нет.
Привет! У вас заключение дублирует заголовок.
Привет! Спасибо большое, исправили
Привет! Спасибо за статью, действительно интересно как эту задачу решают другие исследователи. Но мне не очень понятен следующий момент:
А что делать, если продукт еще не запущен? Как понять, как он будет работать для пользователя? Мы придумали такое решение:
1. Найти презентационные материалы, где показывают экраны будущего решения.
2. Составить из них User Flow, который покажет, каким маршрутом нужно двигаться пользователю, чтобы достичь своей цели
Я же правильно понимаю, что мы говорим про продукт конкурента? У меня просто разрыв шаблона - как найти презентационные материалы с будущими решениями у конкурентов?
Привет! Спасибо за положительный отклик о статье! По поводу презентационных материалов. Компании анонсируют выход продуктов - описывают будущие функции. Стартапы иногда показывают макеты интерфейсов.
Привет! Спасибо за статью)
Всё круто, логично.
Единственное, мне показалось, что статья скорее про подход к сбору данных, а не про выводы на их основе. Вероятно, выводы вы дали самим клиентам и просто их не описали)
Подскажите, а в случае подобного кейса, когда выходит фича конкурента и для ричерча привлекают вас, даете ли вы заказчику кроме массива информации еще и выводы/рекомендации в стиле "надо запускать" или "это применимо у них, но не у вас"?
Как вы подходите к тому, чтобы сформировать такие выводы и рекомендации?
Привет!
Все верно, выводы и рекомендации остаются у клиента:
- потребности и проблемы ЦА, как сейчас решают, и какие тут есть возможности для нашего клиента;
- стоит ли запускать точно такую же фичу с учетом знаний о ЦА, и если нет, то какую следовало бы.