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