Неопределённость под контролем. Кейс исследований в работе аналитика
В традиционном представлении бизнес-аналитик — это «собиратель требований» и переводчик между бизнесом и разработкой. Сегодня этого уже явно недостаточно. Генерацию пользовательских историй можно доверить ИИ, а ценность профессионала смещается в сторону стратегического мышления и исследовательской работы. Аналитик не просто посредник, а тот, кто снижает неопределённость для команды и руководства.
Недавно я говорила об этом с коллегой и услышала неожиданный вопрос: «А ты всегда любила работать с неопределённостью?» Вообще-то никто не любит неопределённость, она вызывает стресс и тревожность. В контексте задач аналитика для меня фраза «работать с неопределённостью» означает умение взять её под контроль. И в этом смысле всегда интересно встретить нестандартную задачу, которую можно решить.
В этой статье я расскажу об одном кейсе, где для снижения неопределённости использовался каскад исследований. И, как водится, я сделала ошибку, а потом её исправила. Понять почему неправильно выбрал фреймворк даже интереснее, чем идеальный план с самого начала.
Задача звучала так: «Пользователи испытывают сложности на странице поиска, нужно что-то менять». У такой задачи нет адекватных критериев приемки и сама формулировка содержит допущения. «Пользователи испытывают сложности» — это слишком универсально. Много вы знаете приложений, где ни разу не задумались как выполнить какое-нибудь действие? Почему утверждается, что именно нашим пользователям сложнее других? Какого рода сложности искать и как понять, когда остановиться в поисках? В общем, первым делом нужно снизить уровень неопределенности.
В моем случае был выбран Usability Test, так как приложение в эксплуатации, предназначено для использования только внутри компании, так что целевая аудитория понятна.
Подготовка. Я обычно пользуюсь теми же подходами, что и исследователи пользовательского опыта, то есть составляю полный план исследования, чтобы ничего не забыть. Нужно не забыть:
📍зафиксировать цели исследования и критерии завершения;
📍оценить необходимое количество респондентов;
📍продумать требования к респондентам и способы их поиска;
📍продумать сценарии/вопросы для респондентов;
📍продумать инфраструктурные моменты (на каком стенде проводить? у всех ли респондентов есть доступ? будет ли установлена нужная версия? можно ли видеть действия пользователя? можно ли делать запись экрана?);
📍продумать, что нужно написать в приглашении на интервью и какие вводные дать респонденту при встрече.
Для частых и небольших проверок такой «размах» может оказаться пустой тратой времени, но здесь я решила заморочиться, чтобы собрать поведенческие характеристики, которые до меня никто не собирал, и при этом охватить разные группы пользователей. Честно говоря, прежде чем потратить свое время и время коллег, лучше сосредоточиться.
Выбор респондентов. Количество респондентов можно рассчитать с помощью калькуляторов. Если поискать по фразе «расчет количества респондентов для качественного исследования», то их найдется много, не хотелось бы рекламировать никакой конкретно. Для расчета нужно знать объем целевой аудитории (сколько у вас всего пользователей) и понимать планируете ли вы сравнивать поведение разных групп или разные дизайны. В моем случае хватило 7-8 респондентов.
Критерии выбора респондентов я придумала такие:
📍Коллеги не общались с командой по вопросам выявления требований в последние 6 месяцев. Хотелось услышать свежее мнение, а не общаться с руководителями, всегда готовыми перейти на язык выставления «хотелок».
📍Разделить респондентов на тех, кто меньше года работают в нашем подразделении (новички в продукте) и тех, кто работает дольше (опытные пользователи).
Так как наши пользователи — сотрудники компании, то эти критерии я разослала руководителям направлений с просьбой выделить респондентов. С продуктом для внешнего рынка было бы сложнее.
Проведение теста. На общение с каждым респондентом я выделила полчаса (вполне достаточно для нашего сценария поиска) и, чтобы не забыть свой план вопросов, записала основные сценарии. В этом интервью речь шла об инструменте, где пользователи по пяти фильтрам поиска могут выбрать задачу для работы. Мои вопросы получились примерно такими:
- Найдите запись, с которой вы работали в ближайшее время.
- По каким признакам вы ее нашли?
- Почему именно такие параметры нужно выбирать?
- Если в результатах поиска несколько записей, то уточните по каким признакам респондент выбрал нужную?
- Что вы можете рассказать о записи по параметрам в результатах поиска на экране?
- Сбросьте выбор фильтров, давайте вернемся к списку всех записей.
- Подскажите, пожалуйста, сколько сейчас записей на странице? Где на экране это видно?
- Подскажите, пожалуйста, сколько всего сейчас записей доступно? Где на экране это видно? Важно ли вам это понимать в вашей работе?
- Какие из записей наиболее важны в вашей работе? К каким вы никогда не возвращаетесь?
- Найдите запись, с которой вы уже завершили работу.
- По каким признакам вы ее нашли?
- Почему именно такие параметры нужно выбирать?
- Если в результатах поиска несколько записей, то уточните по каким признакам респондент выбрал нужную?
- Как часто вам приходится возвращаться к старым записям? В каких случаях это бывает нужно?
- Какие рабочие задачи вы обычно решаете с помощью этой страницы? Приходится ли дополнительно чем-то пользоваться (записи карандашом в блокноте, списки в Excel, вывод чего-то на второй монитор…)? Прим. Это лучше подметить самому, но если не получилось так построить разговор, то я бы спросила
- Какой из сценариев поиска для вас выглядит сложным или раздражающим? Почему?
- Какой из сценариев поиска для вас выглядит самым полезным? Почему?
- Есть в функционале поиска, о чем мы не поговорили сейчас, но вы хотели бы рассказать?
Итоги первого этапа. Критерием завершения исследования было по факту исчерпание списка респондентов, других метрик не было в задаче, хорошо, что список небольшой. Так как границы поиска не были заданы, то и отчет об исследовании получился огромным со списком из 30 инсайтов, часть из которых мы так и не смогли применить, а часть были далеко не новыми и уже хотя бы раз обсуждались заказчиками или уже лежали где-то на дне бэклога. Когда потом оценила время, потраченное на задачу, то получилось порядка двух недель чистого времени ушло на все интервью и их обработку — так выглядит цена неопределенности.
Следующий шаг борьбы с неопределенностью — расставить приоритеты найденным инсайтам. Я выбрала метод Кано, чтобы понять насколько те или иные функции важны нашим пользователям. Этот метод широко используется UX-исследователями, написано много статей (оставила ссылки ниже) и известные платформы для UX-исследований поддерживают этот метод (Fabuza, Oprosso, например).
Если коротко, то метод Кано позволяет с помощью заданной матрицы вопросов ранжировать список функций по категориям:
📍Обязательные — такие функции для пользователя из ряда само-собой разумеющихся, без которых продукт не может выполнять свое назначение. Например, телефон должен принимать звонки. У этой категории наивысший приоритет.
📍Важные (Одномерные) — эти функции чем лучше работают, тем лучше отношение пользователя к продукту. Например, чем лучше разрешение экрана смартфона, тем больше удовлетворенность пользователей. У этой категории высокий приоритет.
📍Интересные — эти функции вызывают «вау»-эффект, они не обязательно нужны для выполнения задач продукта, но могут вызывать интерес пользователей. Приоритет может быть средним или низким.
📍Безразличные — такие функции лучше отложить или вовсе от них отказаться.
Ошибки. Уже на первом обсуждении полученных приоритетов с заинтересованными сторонами стало понятно, что где-то я ошиблась с выбором метода. Первая же функция из моего топ-листа вызвала вопросы кому и зачем она может быть нужна. Дело оказалось в том, что метод Кано используется для количественных исследований и для получения статистически достоверного результата нужен объем выборки сильно больше, чем у меня был.
Метод Кано не сработал, пришлось выбирать другой, который помог бы отличить субъективное от объективного. Выручил подход Value vs. Effort, который предлагает сопоставить предполагаемую ценность функции с ожидаемыми усилиями по ее разработке.
Когда нужно расставить приоритеты функциям в части юзабилити, ценность можно подсчитать, если оценить время выполнения и частотность операций, на которые повлияет изменение. Например, чтобы скачать ежедневный отчет, пользователю приходится проделывать путь через несколько экранов и занимает это в среднем 30 сек с учетом прогрузки страниц и ложных кликов. Пользователь каждый день пробирается таким образом не менее чем к 10ти отчетам. Суммарно в месяц один пользователь проводят 3 часа в переходах между экранами, и если это в деньгах больше, чем затраты на разработку, то этим имеет смысл заняться.
Последний элемент головоломки — это коммуникация. Исследования бесполезны, если их нельзя эффективно донести до команды и заинтересованных сторон, у которых, как известно, короткая продолжительность концентрации внимания.
Здесь выручают подходы из сторителлинга на основе данных. Можно подготовить сводку из пары слайдов, в которой выделены:
- Проблема: подкреплена внутренними данными.
- Контекст: подкреплён исследованиями.
- Варианты решений: подкреплены анализом реализуемости.
- Рекомендация: подкреплена расчётом соотношения риска и выгоды.
В моем случае работа с неопределенностью завершилась тремя задачами в бэклоге и изменением интерфейса поиска. Путь оказался длинным и с ошибками, но удалось вовремя скорректировать курс. Собственно, работа с неопределенностью и складывается из исследований, поиска и проверки гипотез и постоянной корректировки курса.
Я не рассказала детально о методах приоритизации, оставлю несколько ссылок на статьи:
Модель Кано — инструкция по применению
12 методов приоритизации продуктовых целей: RICE, WSJF, KANO и прочие
Как использовать модель Кано для продуктового анализа
Как можно выбрать из двух зол?
