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