7 ошибок модератора в юзабилити-тестировании (Дарья Куликова, ProfsoUX-2015)

Ссылки сюда (2) →

Короткая ссылка: 201504252C

Аннотация

Докладчик

Дарья Куликова

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

За годы проведения тестирований и ведения проектов по тестированиям, у сотрудников нашей компании накопился достаточный опыт, которым хочется поделиться с теми, кто проводит юзабилити-тестирование или только учится это делать.

Ошибки модератора, о которых я хочу рассказать, могут показаться очевидными, но всегда полезно сформулировать их для себя, чтобы держать их в голове и не допускать во время теста.

Видео

on youtube

Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.

Слайды

Тезисы

Тема

Распространённые ошибки модерирования юзабилити-тестирований

Вступление. Краткий рассказ о компании и о себе

Краткая информация о нашей компании — чем мы занимаемся, как давно. Два основных направления — тестирование и проектирование. Кратко о том, как построена наша работа (просто для понимания объем компании, как распределены роли). Чем занимаюсь в компании я, какой опыт (проведения тестирования, ведения проектов и пр.)

О юзабилити-тестировании как инструменте

Рассказ про разные типы ЮТ.

Классическое ЮТ

всё, что делает модератор — озвучивает (формулирует) задание и затем смотрит, как респондент его выполняет. Здесь развилка по методам — можно просить комментировать вслух, а можно и вовсе просить выполнять молча, пока респондент сам не решит, что выполнил задание. Если важно получить результаты продуктивности (время выполнения заданий), респондент не должен комментировать ничего в процессе, а говорить о своих впечатлениях уже позже.

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

Но ЮТ в классическом понимании в последнее время используется реже, модератор всё чаще общается с респондентом, задаёт конкретные вопросы по экранам, по заданиям, по поведению в целом. Получается что-то среднее между ЮТ и глубинным интервью. Не получится избежать общения с респондентом и на этапе, когда тестируется прототип, а особенно бумажный.

Часто на большом количестве дополнительных вопросов настаивают заказчики — им важно именно услышать от респондента, что он не понял тот или иной экран/элемент/текст.

Результаты, которые могут быть получены в том и в другом варианте модерирования, различаются. Будут примеры, что удаётся получить в том или ином случае.

Однако именно когда модератор начинает активно взаимодействовать с респондентом, он и допускает ошибки.

Об основных ошибках и работе над ними я и расскажу.

Основные ошибки

Вопросы с подсказкой

Проблема: Задаются закрытые вопросы вместо открытых. Закрытые вопросы — подсказывают, наводят на ответ. Открытые вопросы — не дают респонденту знаний о том, что интересует модератора. Вопрос: «что вы больше любите — кабачки или баклажаны?» плохой, потому что возможна т. н. эхолалия — повторение последнего слова, высказывания.

Примеры неправильных вопросов

• Насколько вам полезно что-то?
• Насколько вам понятно что-то?
• Вы заметили эту кнопку?
• Вам было легко выполнить задание или нет?

…

Правильные вопросы

• Как вы поняли информацию на этой странице?
• Что вы сейчас делаете?
• Где вы видите эту возможность?
• Почему вы так думаете?
• Зачем вы перешли по этой ссылке?
• Когда вы заметили эту кнопку?
• Зачем вам нужна эта информация?
• Какую информацию/кнопку/ссылку вы стали бы использовать в реальной жизни?

и т. д.

Старайтесь формулировать вопросы так, чтобы они начинались с вопросительного слова. Впрочем, это не панацея, так как даже открытые вопросы можно задавать не вовремя или сформулированные неверное.

Всё понимающий модератор

Существует глобальная проблема, которая проявляется не только в юзабилити-тестированиях, опросах, исследованиях, но и просто в повседневном общении между людьми.

Мы слышим то, что хотим слышать, то, что придумали для себя.

Модератор додумывает за респондента, почему он в ходе выполнения задания повёл себя так, а не иначе, и опираясь на эти свои выводы, задаёт вопросы. Часто бывает ситуация, что модератору кажется очевидным, что респондент видит тот или иной элемент, или, что еще более ошибочно — респондент отдает себе отчет в том, что он видит и понимает это.

Пример

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

Вопрос модератора после завершения задания: «Как вам этот способ оплаты?»

Ошибка в том, что модератор решил для себя, что респондент понял, что именно произошло, хотя это не так.

Правильный вопрос в этой ситуации: после того, как респондент сам сказал, что оплатил покупку, спросить: как вы это сделали? Откуда списались деньги? Почему вы так решили?

Решение в целом

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

Не нужно указывать на какой-то элемент, как будто он уже стал фактом сознания и говорить, например, «а что это за оплата тут, как вы понимаете?» (экран привязки карты).

Респондент а) возможно не видел это, б) не понимал, что это оплата, а вы ему подсказали или наоборот ввели в заблуждение.

Даже если вам кажется, что очевидно, о чем он говорит, спросите его, о чем вы сейчас говорите? можете показать?

Профессиональная лексика

Модераторы обычно знают, какие гипотезы должны быть проверены в ходе теста, на какие вопросы тестирования должны получить ответы.

Но в тест эти вопросы он и переносит в том виде, в каком согласовывал их с заказчиком. Респонденты совершенно не могут понять, о чем речь, или делают вид, что понимают, но отвечают наобум.

Например:

• «Как обычно вы взаимодействуете с мобильным оператором?»
• Или «Какие задачи вы выполняете в интерфейсе?»
• Или «Какие инструменты вы используете, чтобы контролировать свои расходы?»

Для респондента не существует задач в интерфейсе, для респондента не существует взаимодействия, у него есть телефон, который он пополняет, на который звонит и т. д. (будет разбор ошибок в приведённых примерах).

Быстрый модератор

Из-за того, что модератор не выдерживает паузу, не даёт времени респонденту сосредоточиться на той или иной странице, самому изучить ее, результаты тестирования получаются неверными.

Пример: респондент оплачивает мобильный телефон в интернет-банке. На предпоследнем экране, где нужно нажать «Подтвердить», респондент вместо «Подтвердить» нацеливается курсором на «Закрыть», и тут модератор спрашивает: «Расскажите, какие возможности есть на этом экране». Респондент начинает изучать экран и видит «Подтвердить». Данные потеряны.

Решение

Не нужно сразу бросаться задавать вопросы через секунду после появления нового экрана. Нужно создать у респондента ощущение, что ему никто не собирается помогать.

Нужно выдерживать паузу. Говоря, вы подсказываете. Если бы вы не начали говорить, респондент возможно стал бы действовать по-другому.

Если экран действительно нужно обсудить, можно к нему быстро вернуться после выполнения задания или после всех заданий.

Гиперактивное слушание

Ошибка, которую часто допускают модераторы: активно поддакивает, угукают, кивают головой, слушая респондента. Респондент воспринимает это как одобрение, и может продолжать говорить на отвлеченную тему.

Другая, более редкая проблема — подсказки модератора с помощью языка тела. Хмуриться, если респондент делает что-то не так, или наоборот незаметно для себя кивать, наклонять голову подбадривающе — значит подсказывать респонденту, правильно он действует или нет (эти проблемы, конечно, актуальны только если респондент и модератор находятся в одной лаборатории).

Решение

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

Эти же слова, кстати, очень полезны и для следующего кейса.

Проблема: На одну сессию тестирования уходит больше времени, чем запланировано (больше 1.5 часов)

Как решить: помечать в сценарии, сколько времени должно уйти на каждое из заданий. При этом у модератора эта информации должна быть перед глазами во время теста. Более того, у него должно быть часы, чтобы контролировать время на выполнение задания.

Четко должно быть обозначено перед тестом (согласовано внутри команды, с заказчиками), что именно нужно проверить, ответы на какие вопросы получить, что выяснить, какие гипотезы проверить.

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

(Важно всё это четко обозначить в том числе во время пробного тестирования)

Другая причина долгих сессий — модератор не перебивает респондента, если тот начинает слишком много размышлять. Здесь важно видеть золотую середину между тем, чтобы давать респонденту высказаться и тем, чтобы он не начал говорить на отвлеченные темы.

Один из вариантов решения — стандартные фразы модератора, например, «Хорошо, я поняла вас», «давайте продолжим выполнения задания, а к этому вопросу мы вернемся позже» — даже если мы вовсе не собираемся к этому возвращаться.

Бывают респонденты, которые просто сами по себе медленно разговаривают, при этом говорят полезные вещи и по делу. В этом случае сам модератор может начать говорить быстрее, чтобы стимулировать таким образом респондента говорить чуть быстрее.

Модератор не понимает, о чём спрашивает

Еще до того, как составляется сценарий, специалисты оценивают интерфейсы и выдвигают гипотезы — с какими проблемами столкнутся пользователи? Что будет понятно, а что, наоборот, будет понятно? С какими задачами справятся без проблем, на каких возникнут трудности и т. д.

Сценарий создается на основе гипотез и содержит вопросы, которые эти гипотезы проверяют.

Однако бывает, что над сценарием работает один специалист, а тестирование проводит другой. Или тестирование проводят два модератора. Тогда возможна проблема, когда модератор сам не понимает, что проверяет тем или иным вопросом.

Решение этой проблемы многогранно:

• Во-первых, нужно построить работу так, чтобы все в команде четко понимали и глобальные вопросы тестирования, и конкретные гипотезы.
• Во-вторых, сам документ со сценарием теста, должен содержать не только вопросы, но и гипотезы, которые проверяются этими вопросами.
• В-третьих, все подобные проблемы должны сниматься пробным тестированием, где модератор может (и должен) для себя выяснить все неясные ему моменты сценария.

Важно: если один тест проводят два модератора, они должны задавать одинаковые вопросы, не пытаться их переформулировать для того, чтобы, например, респондент лучше понял вопрос.

Это же правило актуально для итерационных или сравнительных тестирований. Чтобы получить данные для одного и того же вопроса, он должен быть задан одинаково в разных интерфейсах.

Есть похожий кейс — это исследование, где не проверяются конкретные гипотезы, а стоят общие вопросы исследования.

Пример — узнать, что в интерфейсе вызывает у пользователей чувство защищенности, безопасности при оплате.

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

Модераторы не выясняют, в чем проблема

Чтобы при анализе данных опираться на факты, эти факты нужно получить. Мы не можем уверенно сказать, что респондент не увидел ту или иную функцию (если только мы не используем для исследования айтрекер), если в явном виде не получили этих данных.

Решение

выяснить логику респондента. Причем не задавать напрямую вопрос «почему вы не завершили оплату?» (респондент, может быть, еще сам не понял, что не выполнил задание), а попытаться понять логику респондента общими вопросами. Попросить рассказать, что происходило.

Например, в тесте приложения мобильного банка для Android была заставка перед приложением, про которую пользователи не понимали, что это, и как ее закрыть. На протяжении первых тестов модератор считал, что респонденты просто не замечают кнопку «Закрыть», а потом стало ясно, что на самом деле они ее отлично видят — но думают, что это кнопка закроет приложение в целом, а не только этот заставочный экран. До тех пор, пока это не выяснилось, модератор не спрашивал, почему они не нажимают на эту кнопку, а просто фиксировал проблему. Точная формулировка проблемы позволила дать более адекватную рекомендацию — а рекомендация сделать кнопку не серой и заметнее — не помогла бы, а может даже наоборот ухудшила ситуацию.

Примечания и отзывы

• Страничка доклада на сайте конференции

Plays:459   Comments:0