Очень часто при разработке и развитии IT-продукта происходят нелепые вещи – фидбек пользователей живёт одной жизнью, а идеи по развитию продукта – другой.

Служба поддержки собирает жалобы и просьбы клиентов, сохраняет его. Список становится бесконечно длинным и не структурированным. В конечном итоге его никто не смотрит.

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

Во время глубинных интервью пользователи не говорят о своих потребностях, а иногда высказывают какие-то решения и требуют их реализовать: «А сделайте-ка мне вот эту фичу! Или я уйду к вашим конкурентам!». Такие решения затрагивают ограничения проекта и часто не вписываются в них. Поэтому о них начинают забывать.

Глубинные интервью – пустая трата ресурсов. Глупо задавать открытые вопросы. Из них мы не поймём, какую задачу ставить разработчику.

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

Как уменьшить количество данных

Человеческий мозг может обработать небольшое количество данных. Он способен одновременно удерживать информацию о 7 объектах (+/- 2). Таким образом перед нами становится задача «уменьшить количество данных». Важно делать это не путём выделения главного, а методом сжатия. Чтоб малое количество данных было репрезентативно первоначальной большой выборке.

Цифры сжать просто. Закинули выборку в excel (или любой другой софт). Посчитали среднюю, медиану и другие интересующие нас значения. И вуаля – данные сжаты, можно делать выводы и просто работать с ними!

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

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

Как выявлять потребности?

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

Изложим этот метод пошагово.

Шаг 1. Расчленяем текст

Берём отзыв пользователя, жалобу или результат интервью. Ищем фразы, за которыми прячутся потребности и отмечаем их. Каждую потребность подписываем, даём ей название. Делаем пометки, чтоб потом было легче вернуться и найти нужную часть текста.

В этой части важно не лгать себе и не додумывать ничего от себя.

Например: респондент говорит во время интервью, что в будние дни у него мало времени на детей. Поэтому в выходные он уделает им всё время. Видимая потребность – проводить больше времени с детьми. Записываем её.

На данном этапе мы можем не понимать, как эта потребность будет касаться нашего продукта. Но всё равно её нужно записать.

В результате проработки всех текстовых данных мы выпишем много потребностей. Обычно 10-15 штук приходится на одно интервью. Рекомендуемое число респондентов для глубинного интервью – 15 человек. В результате мы получаем 150-225 потребностей. В такой большой выборке мы увидим повторяющиеся и более важные потребности для пользователей. А единичные сразу уйдут в сторону.

Обрабатывать обычный разговор во время интервью и искать потребности по началу очень сложно. Но таким образом тренируется эмпатия – полезный навык для маркетолога или владельца бизнеса.

Шаг 2. Кластеризируем потребности

Теперь каждую потребность выписываем на отдельный стикер.

Берём стикеры другого цвета и выписываем на них интересные факты о человеке, инсайты. Клием все стикеры рядом. Обязательно подписывайте на стикерах имена респондентов – так проще возвращаться к подробностям полного интервью.

Итак, на выходе мы получаем целую стену стикеров.

Далее группируем наши потребности в отдельные сегменты (так называемые кластеры). Подумайте, что из стикеров сходе и что можно объединить в группы. В результаты вы получаете 4-8 кучек – кластеров. Для удобства можно организовать их в столбцы.

Теперь каждому кластеру даём название потребности. Например – потребность растить здорового ребёнка.

Шаг 3. Разрабатываем персоны

Для каждого кластера (сегмента) разрабатываем обобщённую персону. Эта персона не должна отражать половозрастную структуру или указывать кто эта персона и чем занимается, где живёт. Нам в персоне важно только то, что потребность растить здорового ребёнка входит в топ-5 его жизненных приоритетов.

Персону нужно называть кратко и понятно. Ей можно придумать имя, например – «Елена». Но проще и удобнее, когда в названии персоны заложена её особенность — «Бухгалтер».

Теперь выделяем ключевых персон, среди всех, которые мы разрабатывали. Выделить можно либо по важности для бизнеса (прибыльности), либо количественно (в каких кластерах было больше стикеров).

Шаг 4. Пишем USER STORY

Метод USER STORY заимствован из agile.

В процессе подготовки часть USER STORY у нас уже будет заполнена, так как информацию мы уже подготовили на предыдущих шагах.

В первый пробел вставляем персону, в последний – потребность.

Я, как «родитель-бухгалтер»

Хочу ____________

Чтоб ребёнок был здоровым.

Пока наша USER STORY ещё не та, чтоб добавить её в беклог продукта. Пока это всего лишь проблема, которую мы берём на брейншторм и на нём обсуждаем идеи и генерируем варианты решения проблемы. Например.

Я, как «родитель-бухгалтер»

Хочу чтобы приложение на телефоне каждый день уведомляло меня о состоянии здоровья ребёнка.

Чтоб ребёнок был здоровым.

После мы можем придумывать решения.

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

Мы получили список тасков. Они отвечают той самой важной потребности целевой аудитории.

Теперь наша USER STORY может быть сформулирована полность и задача соответственно изменится.

Я, как «родитель-бухгалтер»

Хочу чтобы приложение на телефоне каждый день уведомляло меня об аномальном изменении показателей здоровья ребёнка.

Чтоб ребёнок был здоровым.

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

Roadmap выявления потребностей аудитории и превращения в фичи продукта:

  1. Из всего текста выделяем потребности.
  2. Собираем их в кластеры.
  3. Даём им название.
  4. Для каждого кластера называем персона.
  5. Для проработки выбираем персону.
  6. С помощью USER STORY уточняем задачу.
  7. Генерируем решения.
  8. Выбираем и прорабатываем следующую персону.
  9. И так далее.

Было полезно? Тогда оставляете комментарии и делитесь этой статьёй.