Анализ низкой вовлеченности

 large-740

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

Сразу же хочется спросить: “Ну почему они не пользуются?”, но это вопрос не правильный. Вопрос “Как узнать все причины, почему они не пользуются, и распределить их в порядке приоритетов?” более пространный, но и более полезный.

Пять “почему” – полезных и бОльных

5Whys-clean

Sakichi Toyoda создал свой метод пяти “Почему?”, чтобы люди перестали лечить симптомы и начали исправлять коренные причины. Когда возникает проблема, нужно просто задать эти пять вопросов и потом заняться непосредственно устранением проблемы. Примените этот метод правильно, и ваша проблема больше не возникнет.

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

5Whys-messy

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

Через исследования к улучшениям

Messaging

Если ваши пользователи чего-то не делают — не проверяют, не используют, не приглашают друзей — стоит разузнать, почему. Спросите их.

Ab-versus

A/B-тестирование может дать вам локальное решение, но не снабжает реальной информацией. Смените цвет кнопки с зеленого на красный – и увидите минимальное изменение коэффициента использования … но характер этой разницы будет эстетическим, а не основанным на желаниях пользователя, его мотивации понимания преимуществ.

Ранжируйте проблемы

Sankey

Поймите корневую проблему и оцените ее количественно. Это поможет вам расставить проблемы в порядке приоритетов. В свою очередь, это поможет определить проекты, касающиеся опытности пользователей, например: “Нужно, чтобы новый подписчик мог создать отчет самостоятельно, без обращения в поддержку” (это можно протестировать), а также метрику: “Количество обращений в поддержку на созданный отчет должно уменьшиться ” (это можно контролировать).

Если проблемы касаются в основном мотивации пользователей, от функционала лучше избавиться, а затем подумать, зачем его вообще ввели. Вероятно, вы не умеете говорить “нет”. Если проблемы в основном с интерфейсом, подумайте о новом дизайне (вместо чтоб цепляться за корявый старый).

Если ваш дизайн только вводит пользователей в недоумение, то это происходит только потому, что вы не получили обратную связь до того, как отгрузили продукт. Почему так получилось? Как это можно решить? Постоянно спрашивая “почему?”, компании могут решить большие проблемы на том этапе, когда они еще маленькие. Будучи стартапом, вам надо наращивать всё, кроме проблем. Большие проблемы вам не нужны.

По материалам: http://insideintercom.io