Как оценить частотность проблем найденных в ходе юзабилити тестирования? Кейс Циана
Делать количественные выводы по «качественному» юзабилити тестированию так себе затея. Если 5 из 10 пользователей столкнулось с проблемой — это не значит, что 50% пользователей с ней столкнутся. Но как быть, если очень хочется получить количественные данные по частотности проблем, выявленных в ходе юзабилити тестов? Рассказываю свой кейс на примере исследования проблем на форме подачи объявлений на Циан.
Предыстория
Изначально product owner пришел ко мне с запросом понять какие у нас сейчас есть проблемы связанные с формой подачи, так как аналитика показывала что воронка «хромает». До этого мой коллега делал экспертный аудит, но чтобы понять с чего начать работу по улучшению хотелось подтвердить его гипотезы об живых пользователей и, желательно, количественно.
К сожалению, аналитика показывала факт существования проблемы, но не могла подсказать ничего более конкретного, так как на тот момент мы ловили только 2 события:
- Вход на форму подачи
- Публикация объявления
А все что происходило между двумя этими событиями было для нас загадкой. Сейчас мы уже это исправили :-)
Дизайн исследования
Итак, как понять что стоит починить в продукте и в как потом приоритизировать найденные проблемы?
Дизайн этого исследования состоял их двух ключевых этапов, которые шли в параллели:
Качественный этап
Изучение контекста возникновения проблем и ответ на вопрос «Почему?»
Я решила не просто провести обычный юзабилити тест, а провести сравнительное тестирование — сравнить нашу форму подачи с ключевыми конкурентами, чтобы понять на кого стоит ориентироваться. В качестве дополнительной метрики использовала USS (модифицированный SUS), чтобы оценить субъективную удовлетворённость.
Количественный этап
Изучение частотности возникновения проблем и ответ на вопрос «Как часто?»
Используя UX Feedback запустила кампанию по сбору активного фидбэка, чтобы выявить дополнительные проблемы в продукте, которые не подсветились во время тестирования и собрать количественные данные по частотности возникающих проблем
Про юзабилити тестирование
Респонденты были поделены на 2 ключевых сегмента:
- С опытом продажи квартиры
- Без опыта продажи квартиры
Для каждой площадки подбирали респондентов без опыта взаимодействия с ней, оказалось что найти людей без опыта работы с Авито очень сложно :-)
Для «опытных» заданием было повторить их путь и разместить объявление о продаже своей квартиры на площадке.
Для «не опытных» использовала метод «Боливуд», где респонденту нужно было помочь продать квартиру друга, находящегося в бегах заграницей.
Боливуд
В рамках работы в Циан я применяла этот метод уже в нескольких проектов и могу однозначно сказать, что он очень хорошо себя показывает!
Суть метода состоит в том, чтобы погрузить респондента в выдуманных драматический контекст, в котором ему будет необходимо сыграть роль.Корни этого метода лежат в задаче сломать социально-желательное поведение респондента и помочь ему говорить то, что он действительно думает.
По аналогии с методом генерации идей «идеи от третьего лица», вовлекаясь в спроектированный сценарий «Боливуда» респонденту также проще выражать свои эмоции и недовольство сервисом.
Про сбор обратной связи с сайта
Параллельно с проведением юзабилити тестирования я запустила и кампанию по сбору активного фидбэка.
Чем активный фидбек отличается от пассивного?
Пассивный фидбек. Обычно это кнопка пожаловаться в подвале сайта, или в «дальнем» разделе приложения. Туда валится фидбек на все элементы продукта без разбора, поэтому сортировка такого потока задача не из легких. Ключевое отличие от активного фидбека в том, чтобы написать отзыв через такую форму пользователю нужно иметь действительно серьезную мотивацию, поэтому обычно эти формы собирают только самые острые боли внутри продукта (причем не всегда самые репрезентативные).
Активный фидбек. Собирается на конкретном эпизоде пути пользователя. За счет встраивания опроса в пользовательский сценарий мы существенно увеличиваем конверсию в ответ (в нашем случае от 0,1% до 20%) и получаем свежий, горячий фидбэк не отходя от кассы — напрямую из контекста пользователя, а не из сконструированных лабораторных условий.
Кампания со сбору фидбэка
UXFeedback подружился с нашей Google Analytics, это позволило нам сразу сегментировать ответы пользователей на категории: риэлторы, собственники, не авторизованные.
Заходя на форму подачи пользователь через определённое время видел всплывающее окно с вопросом «Удобно ли размещать объявления на нашем сайте?» и вариантами ответа «Да, вполне!», «Нет, есть трудности».
А теперь магия! При выборе варианта «Нет, есть трудности» конверсия в расширенный текстовый ответ была 20%! За 2 недели мы получили 1000 текстовых ответов, с описанием конкретных проблем, с которым столкнулись наши пользователи на форме подачи. Для сравнения, когда мы запускали подобные кампании через Floctary (в этом инструменте отсутствует такая гибкая настройка событий), то, бывало, что за месяц мы собирали всего 6 ответов! Встраивание опроса в пользовательский сценарий в разы поднимает конверсию в ответ.
Комбинирование качественных и количественных результатов
Безусловно, каждый из этапов этого исследования может использоваться самостоятельно, но самый кайф конечно в том, чтобы скомбинировать данные. :-)
USS
Рейтинг USS (User Satisfaction Score) помог понять на каком месте мы находимся относительно конкурентов, чтобы решить насколько срочно нам вообще нужно бежать и чинить что либо.
Сегментация проблем
Обычно я сегментирую проблемы по 3-м категориям:
1. Критические ошибки
Критическими считаются те проблемы, которые блокируют выполнение пользовательского сценария и могут непосредственно влиять на успех заполнения формы подачи. То есть шанс того, что столкнувшись с этой проблемой пользователь уйдет с нашего сайта большой.
2. Барьеры
Барьер — это не техническая ошибка нашей платформы, то есть всё происходит как и было задумано, но пользователь все-равно может раздумать пользоваться нашей проблемой, если столкнется с ним. Барьеры негативно влияют на опыт использования продукта.
3. Баги
Упс! Тут пояснять не буду, баги у всех бывают. :-)
Анализ текстовых ответов
Пожалуй был одновременно самый интересный и самый нудный этап. По завершению всех тестов, когда был понятен контекст возникновения проблем нужно было проанализировать 1000 текстовых ответов и распределить их по категориям для обнаружения частотности.
В итоге я определила частотность всех проблем обнаруженных в ходе юзабилити тестирования и обнаружила еще несколько критичных проблем и багов не выловленных на респондентах.
«Сшивание» данных и табличка вместо отчета
В итоге вместо привычного много страничного отчета у меня получилась небольшая табличка в Google Sheets с топом проблем в разрезах по сегментам и платформам и, что самое классное, в ней присутствовала частотность ошибок. Данные по контексту возникновения юзабилити проблем из «качественника» были дополнены частотностью возникновения из «количественника» .
Заключение
Если ваши продакты вечно клянчат у вас количественное подтверждение и уже надоели вам с вопросом «А сколько пользователей столкнулось с этой проблемой на тесте?» — то возможно вам стоит повторить описанный мной эксперимент. :-)
Что еще можно сделать?
Комбинировать количественный и качественный сбор данных в рамках одного исследования — хорошая практика. Но если говорить про масштабирование этого метода, то мне кажется что его можно и нужно оптимизировать с помощью CJM.
У многих есть CJM, но мало кто с ним действителньо работает. Мне кажется очень хорошей историей запускать кампании по активному сбору фидбека на ключевых эпизодах пути пользователя, чтобы:
А. Собирать клиентские метрики по каждому эпизоду
Многие собирают NPS, но что нам дает эта «средняя по больнице» цифра? Как понять что и где стоит улучшить, чтобы вырастить эту цифру? Собирая CES (Customer Effort Score) или CSAT (Customer Satisfaction) на конкретных эпизодах мы сможем понять где конкретно и почему в продукте возникают проблемы.
Б. Точечно собирать фидбек по отдельным элементам/функциям продукта
Убиваем двух зайцев одним ударом: экономим время на категоризацию (собираем фидбек только по нужной нам теме) и вовлекаем пользователя оставить отзыв (за счет встраивания в сценарий получаем более высокую конверсию в ответ). Например, выкатили новую функцию — добавили опрос, сразу собрали «горячий» фидбэк; или появилась гипотеза — сделали опрос, собрали данные напрямую из контекста.
Лично я вижу такой подход одним из наиболее перспективных для формирования целостного взгляда на продукт и отслеживания изменений в пользовательском опыте.
