Как проводить исследование пользователей

Проводить исследование пользователей

Как правильно проводить исследование пользователей? Какие виды исследований существуют и какие инсайты для своего продукта можно найти?

Попробуйте себе только представить, что вы ошибаетесь. А теперь, попробуйте представить, что вы крупно ошибаетесь. Представили? Скажу правду, так бывает.

Для кого вы делаете продукты? Наверное для пользователя? Если так, то давайте покиваем в экран. Но, как бы это парадоксально не звучало, тестировать продукты тоже нужно на нем (на пользователе). Очевидно? Да не всегда.  Одна из самых опасных ловушек поджидает каждого из нас прямо за углом. Мы думаем, что знаем, знаем “что им нужно”, вкладываемся силами, временем, ресурсами, а на выходе получаем провальные идеи, гипотезу, продукты. Не надо так делать, давайте проведем исследование.

Зачем проводить исследование

На самом деле для двух основных целей: получить идеи для развития продукта и узнать на сколько они востребованы у пользователя.

Исследование продукта

Самые ценные данные, это те, что позволяют вам сделать выводы и на их основе качественно что-то изменить в своем продукте. Качественно, в смысле сделать то, что принесет профит пользователю и бизнесу.

Проводить исследование нужно, если вы не хотите провалиться со своим продуктом. Без исследований, вы будете, как тот еж в тумане. Вроде что-то думаю, а что полетит или нет, не знаю.

Два вида исследований

Исследования делятся на два вида: качественные и количественные. Каждый из них отвечает на свои вопросы.

Количественные и качественные исследования

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

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

Если изобразить процесс на схеме, то получится что-то вроде этого:

Проверка идей

Работает так: вы проводите качественное исследование, набираете инсайтов от пользователей, задаетесь вопросом “А что, если этот функционал правда так важен и как это проверить?”. Проводите количественное исследование и понимаете масштаб важности. Только после этого в вашем бэклоге должна появится задача.

Как проводить исследование

Для качественных исследований и поиска идей обычно используют:

  • интервью
  • опросы
  • фокус группы
  • анкеты

Вопросы все открытые (не подразумевают ответы да/нет):

  • Что вам не нравится?
  • Почему?
  • Как вы это делаете?
  • Зачем?

Задача: вытащить “боли” пользователя.

Для количественных исследований чаще всего используют:

  • опросы
  • тесты
  • данные аналитики

Вопросы:

– Беспокоит ли вас это?

– Как часто вы сталкиваетесь с этим? (варианты ответов)

– Оцените по 10 бальной шкале на сколько это вас беспокоит?

Задача: максимально у бОльшего кол-ва пользователей спросить “болит” или нет.

Пример: на кошках

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

Бизнес: в зависимости от показателя любимца рекомендуется посетить врача или же изменить питание. Реклама кормов и вет.клиник.

Задача: увеличить вовлеченность пользователей приложения.

Если вы ударялись мизинцем о ножку шкафа и хотите знать, когда появятся новые материалы в блоге, то подписывайтесь на наш telegram канал!

Телеграм канал alexcouncil.com

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

Для тестирования вы запустили эксперимент с пушами на часть аудитории приложения (а/б тест) и выяснили, что 70% пользователей активно кликают на пуши и отводят своих питомцев ко врачу. Гипотеза подтвердилась, обновление выпустили на всех, увеличили вовлеченность.

Нюансы

Вот и все казалось бы, инсайты вытащили, превратили в гипотезы, спросили у большого количества пользователей и победа! Хех, если бы так все было просто.

Проводить исследование пользователей

Вот такие они эти пользователи: спросишь их про то, что им важно, стараешься ради них, а они тебе еще и врут.

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

Подобные ситуации встречаются часто потому, что “пощупать” функционал до того как он разработан пользователи не могут. То есть, их представление о “нужности” облачное. Один думает, что это будет работать так, другой по-другому. Разница в воображении у людей  добавляет тебе, как проектировщику интерфейсов,  “легкую неопределенность”. Ты думаешь, вот так сделаю, ведь понятно будет, а потом, раз, и не понятно.

Плюс, сила контекста. Когда пользователь представляет себе новый функционал, он представляет себе и контекст, в котором будет его использовать. Но сказать наверняка никто не может, как будет вести себя в будущем в конкретной ситуации, поэтому снова мы можем пролететь с ожиданиями. А что же тогда делать?

Ожидание и реальность пользователя

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

Прототипы позволяют вам наблюдать за тем, как реальные пользователи взаимодействуют с функционалом, какие есть блокеры и какие ожидания от интерфейса необходимо оправдать. Они могут быть сделаны из бумаги (low fidelity), а могут состоять из полноценного функционала, вплоть до закрытых версий приложения (тестовые сборки), лендинг пейджев и прочего.

Я писал про прототипы более развернуто тут, можно почитать и выбрать для себя подходящий вариант. Ключевая мысль в том, что вы не пилите функционал, пока он не пройдет реальный тест у пользователей. Тем самым экономите кучу ресурсов и страхуете себя от провала.

Пилюля правды

Хочется добавить, что в исследованиях все очень сильно зависит от самого вопроса и от того, кто его задает. Когда вы напрямую спрашиваете у своего товарища, как ему эта идея, то скорее всего он скажет, что вполне себе неплохая или же смягчит ответ, чтобы вас не обидеть.

Customer development

 

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

Еще пример: но с прототипом

Мы провели несколько интервью с пользователями и вытащили, что многие упомянали функцию поиска в нашем каталоге одежды на сайте. Родилась гипотеза: “А правда ли пользователям нужен поиск?”.

Если мы просто проведем опрос на сайте и спросим “Нужен или нет поиск” с двумя вариантами ответов, то получим, что 50% сказали “Да”. Значит надо разрабатывать. Разработаем, выпустим поиск на всю аудиторию, снимем данные и увидим, что по факту пользуются поиском 2%. Вот тебе и потраченный ресурс.

Что делать? Можно запустить интерактивный прототип с поиском и максимально приближенным к реальности дизайном. Прогнать его на реальных пользователях, снять метрики и увидеть, сколько на самом деле людей будут им пользоваться.

Проверка гипотезы на пользователяхПроверка гипотезы на пользователях

Опять же, запустите a/b тест на часть аудитории. Выведите иконку поиска в меню и показыайте ее, к примеру, 2 недели 30% вашей аудитории, а по клику на нее, поставьте обычный попап со строкой ввода. Пользователь введет запрос, нажмет “ввод”, попап обновиться и вы скажите ему, что сейчас разрабатываете поиск и его (пользователя) участие сильно помогает вам сделать качественный поиск.

Инструменты для проверки гипотез:

  • Google Tag Manger.
  • Функционал для a/b тестов.
  • Различные всплывающие окна, попапы.
  • Отдельные посадочные страницы и многое другое.

Больше инструментов для проверки гипотез ищите в том же материале, который рекомендовал ранее.

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

Инсайт

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

Итог

Проводить исследование мало того что полезно, так еще и очень интересно. Вы общаетесь с пользователями, накидываете идеи, создаете различные прототипы и смотрите, как реальные люди ими пользуются. Вносите корректировки и создаете то, что правда приносит пользу. Нет ничего круче, чем видеть, как твоим продуктом пользуются много людей и им он нравится. Проводите исследования, чтобы делать классные продукты и помните, много исследований не бывает!

Алексей А.


Читайте также:


Еще один сильный ролик от Nike. Про женщин, которые не бояться выражать свои эмоции.



1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...

Добавить комментарий

Введите ваше сообщение и email.

*