Например, в ходе тестов 4 респондента не могут использовать фильтр, а 4 других считают фильтр очень удобным. Наши действия?
Ведущий юзабилити-специалист в UsabilityLab Ирина Денисова предлагает два варианта:
1️⃣ Первый вариант: отразить проблему в списке юзабилити-проблем, а в хороших решениях отметить ту же функцию как удачную. «Все очень круто, нужно переделать». Ирина пишет, что это неудачный вариант, и это так и есть.
2️⃣ Второй вариант мы процитируем дословно:
Вариант 2. (как лучше):
• в описании юзабилити-проблемы указать, что несмотря на сложности одних респондентов, другие посчитали решение удачным. Но т.к. проблема выявлена, ее нужно устранить,
• если функция важная или ее изменения очень затратны / не выгодны для бизнеса, предложить провести количественник, чтобы сделать более достоверные выводы по фиче,
• если удачным решение отметило малое количество респондентов или преимущества его незначительны, вообще не отмечать фичу как удачную в отчете, а обратить внимание на проблему.
ВАЖНО: Если функция объемная и проблемы встретились только в одной ее части (например, непонятны формулировки параметров в фильтре), а само наличие функции или другая ее часть (например, вид списков в фильтре) действительно хорошо реализованы, то стоит отразить это и в проблемах, и в удачных решениях, заострив внимание именно на каждой ОТДЕЛЬНОЙ части функции.
Мы тестировали фильтры, и это реально боль. Очень многие люди не опознают разные иконки с фильтрами – говорят, что это «какая-то воронка, и непонятно, зачем она тут». А когда опознают, то используют и правда с трудом. Поэтому в некоторых гайдлайнах общая рекомендация для фильтров при проектировании - сбрасывать фильтры после выхода пользователя, иначе поддержку просто разорвут.
Но обычно для команды, которая работает над проектированием интерфейса, важно не что вы им напишите в отчёте. Команде важно понимать, почему их интерфейсные решения хороши или плохи.
ЧТО не так с фильтрами для одних респондентов? ПОЧЕМУ для других респондентов фильтры проблемы не представляют?
И дело не в том, как вы уложите противоречия в отчёт. Ответ на вопрос «почему пользователи так по-разному используют фильтры?» нужен, чтобы понимать, КАК менять интерфейс.
На вопросы «Что не так?» и «Почему..?» количественник ответа не даст. Но мы можем это выяснить, поговорив с людьми.
Поэтому до количественника и до написания отчёта было бы лучше выполнить вариант 3️⃣:
На время отойти от утвержденного сценария теста и уделить внимание анализу причин: почему эти люди проходят сценарий по-разному?
Например, сразу после выполнения сценария спросить – о, как интересно, у вас получается использовать фильтр. Расскажите, как вы этому научились? (и уточнять до тех пор, пока опыт респондента не станет нам понятен)
И тогда, скорее всего, выяснится, что у этой части людей с подобными фильтрами есть опыт в других приложениях.
И тогда вы сможете посмотреть, как это реализовано там, где эти люди научились использовать фильтры, и перенять эти практики.
Как только мы узнали, почему люди проходят тесты по-разному – собираем команду и обсуждаем, что делать дальше.
- Может, нам нужно поменять критерии рекрута, если к нам приходит слишком много опытных, а нам нужны новички.
- Может, нам лучше, наоборот, расширить рекрут на две группы - опытных и новичков и сравнить их между собой.
- Может, нам нужно переделать прототип, и не сжигать тесты зря
- Может, нам нужно сделать обучающее видео для нашего продукта или изменить онбординг.
Но в любом случае важно действовать быстро.
💽 @PostPostResearch