Как я искала сложности и что из этого вышло
#опыт #исследования

Я тут пообещала поделиться опытом каскадных исследований. Это первый пост, в котором начинаю выполнять обещание.

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

Хитрость в том, что у такой задачи нет адекватных критериев приемки и сама формулировка содержит допущения. «Пользователи испытывают сложности» - это слишком универсально. Много вы знаете приложений, где ни разу не задумались как выполнить какое-нибудь действие? Почему утверждается, что именно нашим пользователям сложнее других? Какого рода сложности искать и как понять, когда остановиться в поисках? Первым делом нужно снизить уровень неопределенности. В моем случае был выбран Usability Test, так как приложение в эксплуатации и понятна группа пользователей (приложение для сотрудников конкретного подразделения компании).

Guide Я обычно составляю полный план исследования, чтобы ничего не забыть. Нужно не забыть:
📍зафиксировать цели исследования и критерии завершения
📍оценить необходимое количество респондентов
📍продумать требования к респондентам и способы их поиска
📍продумать сценарии/вопросы для респондентов
📍продумать инфраструктурные моменты: на каком стенде проводить? у всех ли респондентов есть доступ? будет ли установлена нужная версия? можно ли видеть действия пользователя? можно ли делать запись экрана?
📍продумать что нужно написать в приглашении на интервью и какие вводные дать респонденту при встрече
Для частых и небольших проверок такой «размах» может оказаться пустой тратой времени, но здесь я решила заморочиться, чтобы собрать поведенческие характеристики, которые до меня никто не собирал, и при этом охватить разные группы пользователей. К тому же вряд ли мне часто будет предоставляться шанс отвлечь коллег от работы.

Выбор респондентов Количество респондентов можно рассчитать с помощью калькуляторов. Если поискать по «количество респондентов для качественного исследования», то их найдется много, на курсе в ВШЭ нам советовали такой. Для расчета нужно знать объем целевой аудитории (сколько у вас всего пользователей) и понимать планируете ли вы сравнивать поведение разных групп или разные дизайны. В моем случае хватило 7-8 респондентов.

Критерии выбора респондентов я придумала такие:
📍Коллеги не общались по вопросам выявления требований в последние 6 месяцев. Хотелось услышать свежее мнение, а не общаться с руководителями, всегда готовыми перейти на язык выставления «хотелок».
📍Разделить респондентов на тех, кто меньше года работают в нашем подразделении (новички в продукте) и тех, кто работает дольше (опытные пользователи).

Так как наши пользователи — сотрудники компании, то эти критерии я разослала руководителям направлений с просьбой выделить респондентов. С продуктом для внешнего рынка было бы сложнее.

Проведение теста На общение с каждым респондентом я выделила полчаса (вполне достаточно для нашего сценария поиска) и, чтобы не забыть свой план вопросов, записала основные сценарии. Файлом с примерами вопросов поделилась тут

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

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