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

 large-740

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

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

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

5Whys-clean

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

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

5Whys-messy

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

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

Messaging

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

Ab-versus

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

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

Sankey

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

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

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

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

  • Artjom Serdyuk

    А у кого спрашивать «почему»? Не уверен, что мои энд-юзеры готовы ответить 5 раз на мои «Почему вы не пользуетесь…» и «Почему так получилось…».

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

      • Artjom Serdyuk

        Я пробовал — получилось очень плохо. User testing выявил проблемы, но когда Product team в составе 5 человек попыталась найти причину проблем и сгенерировать решения…

        Из-за разных точек зрения и невероятного количества вариантов все закончилось конкретной руганью и затею пришлось отложить. Получилось, что user testing прошел по ходу зря: проблемы нашли, а о причинах проблем и вариантах решения договориться не смогли.

        • Ну ОК, а пользователи-то что сказали в этом случае? Не смогли объяснить в чем проблема?

          • Artjom Serdyuk

            Пользователи вполне определенно ответили (что-то типа «Не хватает того-то и того-то» или «Нет четкого Call to Action»).

            Проблема в том, что статья-то советует задавать «Почему» 5 раз. А юзер тестинг — это обычно тестирование user flow, пользователь сделал замечание и пошел себе дальше, его не остановишь вопросом «А почему вам тут не хватает ссылки на список?».

            Поэтому приходится додумывать ответы на эти «Почему» самим. Хотя может быть, стоит спросить у пользователей ещё раз.