Когда один респондент хорошо, а два — лучше: парные тесты в UX-исследованиях
В этой статье я сделала обзор основных методик проведения парных тестов (co-discovery, teaching, coaching) и рассказала о своем опыте их применения в исследованиях. Для тех, кто захочет узнать больше, в конце статьи есть ссылки на подробное описание каждого метода.
Свой первый парный тест я провела случайно. Я проводила удаленное юзабилити-тестирование с респондентами из регионов и в самом начале очередного звонка обнаружила, что по другую сторону экрана от меня сидят два человека: наш респондент был смущен непривычной для себя ситуацией интервью и позвал на помощь друга. Я была начинающим модератором, поэтому не смогла настоять на том, чтобы проводить интервью без помощников, но к счастью, в тот момент это сработало на пользу. Вскоре респонденты забыли обо мне и полностью погрузились в ситуацию использования личного кабинета: пытались выбрать тариф и оплатить, попутно спорили, матерились, курили сигареты одну за другой (когда осталась одна сигарета, они курили её пополам, словно разделяя нелегкую долю пользователей запутанного интерфейса). Второй респондент за время теста успел поссориться с женой, которая ему позвонила: “Свет, нет, я тебя не встречу. Я Сереге с интернетом помогаю. Нет, не в гараже. Не кричи на меня! Всё, сама доедешь!”. В общем, всего за час я набрала достаточно материала для отчета — в раздел с негативными последствиями юзабилити-проблем.
Потом я проводила парные тесты сознательно, а в тот день я отправилась гуглить и узнала, что это был:
Co-discovery method
В этом варианте парного теста оба респондента не знакомы с системой и впервые изучают её во время теста. Получив задание, респонденты начинают совместно решать задачу, по ходу обсуждая возможные решения и возникающие проблемы. Оба респондента открывают для себя систему впервые, но каждый со своей ментальной моделью и познавательной стратегией, и это дает возможность увидеть реальность с новых сторон.
Что наблюдаем:
- в какой последовательности респонденты решают задачу,
- как обсуждают возможные стратегии решения,
- в какие моменты у них возникают споры,
- какие элементы системы непонятны, как респонденты объясняют их друг другу,
- как обсуждают затруднения, какие слова при этом используют.
Полученные данные помогают найти проблемные места системы и правильно построить онбординг или обучающий режим (инструкции, подсказки, туториалы).
В классическом варианте этой методики респонденты работали с десктопными системами (ПК или ноутбук), при этом один респондент использовал только клавиатуру, а второй мышку. Тыкать пальцем в экран не разрешалось. Эти ограничения должны побуждать респондентов больше использовать речь, чтобы договариваться между собой: они вынуждены проговаривать каждую деталь, и наблюдатели получают больше вербального материала для понимания происходящего.
Мне эти ограничения кажутся неестественными и не очень полезными: так мы создаем дополнительные затруднения, которые могут замаскировать реальные проблемы. Я даю респондентам возможность самим решать, кто и когда будет нажимать на кнопки, и у них это происходит естественно: один говорит, куда нажимать, второй делает, если согласен, а если не согласен, они обсуждают или меняются местами.
Мы использовали метод co-discovery для тестирования интерфейса онлайн трансляций, когда приглашали стримеров, которые и в жизни проводят вместе прямые эфиры. Инициатива легко переходила от одного к другому: в основном, в перерывах между задачами, когда они обсуждали результат. Иногда кто-то в ходе решения задачи говорил: а давай я попробую, — и тогда они менялись ролями в процессе.
Teaching method
Этот метод считают альтернативой методике think-aloud (мысли вслух): в этом случае один из респондентов самостоятельно изучает интерфейс, а потом объясняет неопытному респонденту, как им пользоваться. Его объяснения позволяют узнать, как он понял принципы взаимодействия с системой и что осталось непонятным. Эти объяснения дают больше полезной информации, чем проговаривание своих действий:
- “мысли вслух” — непривычная задача для большинства людей, никто в реальной жизни не озвучивает свои действия и мысли в процессе решения задач, поэтому всё поведение респондентов становится менее естественным;
- в отличие от разговора с модератором, когда респондент может стесняться своей неопытности, он более уверенно и спокойно себя чувствует с похожим на себя неопытным пользователем.
Что фиксируем:
- с чего начинает рассказ, в какой последовательности объясняет,
- что понял неправильно,
- что осталось непонятным,
- какими словами объясняет и называет элементы,
- какие вопросы задает второй респондент и как отвечает первый.
Мы использовали эту методику в тестировании обучающего режима (туториала) в мобильной игре. В первой части исследования мы провели классический плейтест, где респондент изучал игру и играл самостоятельно, а потом обсуждал свои впечатления с модератором. Уже тогда стало понятно, что туториал нужно переделать, и чтобы собрать больше данных для перепроектирования, мы с командой решили провести парные тесты.
Для этого мы попросили респондентов поиграть в игру самостоятельно в течение 1–1,5 часов (для мобильных игр этого более чем достаточно, чтобы хорошо познакомиться с игрой), а потом каждый из них объяснял принципы игры неопытному пользователю. Результаты были поразительными: оказалось, что даже через полтора часа игры пользователи не понимали многие механики сражений и совсем не понимали метагеймплей (часть игры вне сражений). Обычно пользователи играют на смартфонах в перерывах между делами, поэтому игровые сессии там короткие, и важно быстро привлечь и удержать внимание нового пользователя — буквально за первые 15 минут после первого запуска игры. Судя по статистике, нашей игре это не удавалось, а тесты — как классические, так и парные, — показали, почему это происходило. Слушая, как “опытные” респонденты рассказывали про игру неопытным, мы понимали, что они не поняли принципы боя и прокачки персонажей. Туториал им совершенно не помог, а то, что респонденты понимали правильно, они узнали за счет своего опыта, который был им отчасти навязан условиями участия в исследовании. В реальной жизни они, скорее всего, не стали бы играть так долго.
Coaching method
В этом варианте из двух респондентов один является опытным пользователем системы, второй — новичок. Опытному респонденту дают задание: “Объясните второму человеку, как пользоваться этой системой, таким образом, чтобы он мог быстро и легко её освоить”.
Этот метод мы использовали в тестировании обучающего режима клиентской игры на десктопе: как и в предыдущем кейсе, команде нужно было собрать больше данных для создания нового туториала. Мы имитировали ситуацию, которая бывает в реальной жизни: когда увлеченный геймер показывает любимую игру своему другу, зашедшему в гости. Опытные респонденты были игроками с высокими уровнями в игре, а неопытные — представители целевой аудитории, которые могли играть в похожие игры, но нашу игру видели впервые.
Результаты были для нас неожиданными: рассказы опытных геймеров совершенно не совпадали с туториалом, который был в игре, зато были очень похожи между собой. В рассказах опытных геймеров повторялись одни и те же блоки в похожей последовательности, в отличие от туториала, в котором этой информации не было.
В этом исследовании мы также сравнивали первый час игры после самостоятельного знакомства с помощью туториала (первая часть исследования) и после обучения под руководством опытного геймера (вторая часть). В coaching-тесте респонденты не испытывали тех проблем, которые были у респондентов из первой группы, потому что опытные геймеры передали им действительно полезную информацию. Кроме того, в своих итоговых впечатлениях респонденты оценивали игру намного выше. Конечно, отчасти это было связано с тем, что общение с опытными геймерами заражает их эмоциональным отношением к игре. Но помимо этого респонденты перечисляли интересные механики, которые их зацепили: респонденты, которые изучали игру самостоятельно, сами не успели обнаружить эти механики, а туториал о них не рассказывал. Результаты исследования подтвердили гипотезу команды о том, что туториал в текущем виде бесполезен, и дали материал для проектирования нового обучающего режима.
Респонденты
Всем, кто уже провел хотя бы несколько исследований, известны проблемы, которые возникают при рекрутинге для респондентов. В случае с парными тестами эти проблемы закономерно умножаются на два, особенно болезненной может быть стоимость рекрутинга, если его проводят с помощью агентства. Но есть и хорошая новость: в некоторых случаях респонденты сами предлагают “прийти с другом”, и это отличный повод провести парный тест, если цели исследования, опыт респондентов и назначение системы это допускают.
В некоторых статьях о парных тестах пишут, что нужно приглашать респондентов, которые знакомы друг с другом, поскольку им будет комфортнее общаться. Я не совсем согласна с этим: если есть такая возможность, то можно пригласить знакомых, но нужно учитывать два момента.
- Хорошо знакомые люди могут быть немного менее полезны, чем малознакомые: они понимают друг друга с полуслова, и бывает, что им достаточно пары междометий, чтобы что-то объяснить второму. Малознакомые вынуждены говорить подробнее, чтобы убедиться, что понимают друг друга, и мы получаем больше полезных данных.
- Дискомфорт от общения с незнакомым человеком уходит, как только респонденты увлекаются общей деятельностью. Кроме того, мы подбираем людей не только с нужным опытом, но и похожих по полу и возрасту, так что респондентам достаточно легко найти общий язык. А еще мы предлагаем респондентам чай, кофе и печеньки — совместная еда тоже сближает.
Области применения
- Интерфейсы профессионального программного обеспечения. Можно моделировать ситуации, когда новые сотрудники при освоении ПО обращаются за помощью к опытным или при внедрении новых программ в работу сотрудники совместно их изучают.
- Интерфейсы, в которых возможна совместная работа: например, выбор и покупка в ecommerce.
- Видеоигры.
- Тестирование доступности интерфейсов для пользователей старшего возраста: можно моделировать ситуацию, в которой взрослый ребенок помогает своему пожилому родителю освоить новый интерфейс.
…И вообще любые системы, в которых возможна совместная деятельность двух пользователей.
Ограничения
- Парные тесты подходят только для тестирования первого опыта взаимодействия пользователя с системой, т.е. один респондент всегда должен быть неопытным. Проводить парные тесты с двумя опытными пользователями бесполезно: скорее всего, они будут много и подробно говорить о наболевшем, но пропустят то, что “болело” раньше и к чему успели привыкнуть и могут даже не осознавать, хотя проблема на самом деле осталась.
- Парные тесты сложно проводить удаленно. Хотя в самом начале статьи я рассказала как раз о таком кейсе, в целом, парные тесты сложнее проводить удаленными способами, поскольку часто не понятно, какие действия выполняет первый или второй респондент.
- Никакого айтрекинга: во-первых, это сложно организовать технически (как минимум, нужны две пары очков), во-вторых, респонденты в процессе много разговаривают между собой, а во время разговора появляются “мусорные” фиксации, которые не содержат полезных данных для анализа.
И напоследок коротко о преимуществах парных тестов
- Парные тесты хороши тем, что отчасти снимают неестественность лабораторных исследований. Даже если опыт респондентов отличается, они находятся в равной ситуации теста, поэтому они не стесняются друг друга и более спонтанно выражают свои эмоции, чем с модератором, который обычно старается быть нейтрально-приветливым. В результате тесты получаются более эмоциональными, что особенно важно, когда за тестами наблюдает команда продукта.
- Взаимодействие двух пользователей позволяет открыть инсайты, которые невозможно найти при классическом юзабилити-тестировании, ограниченном гипотезами модератора и его знанием системы. Респонденты ничего не знают о бизнес-задачах и конверсии, зато они полностью погружены в решение задачи и свободно обсуждают её друг с другом, поднимая темы, которые могли ускользнуть от исследователя при составлении списка вопросов для сценария.
Если два респондента могут быть полезнее одного, скажет вдумчивый читатель, может быть, лучше позвать сразу нескольких людей? Протестировать интерфейсы на фокус-группах? Но нет, лучше не будет. Почему нельзя проводить тестирование интерфейса на фокус-группе, я расскажу в следующий раз, это история для отдельной статьи.
Ещё почитать о парных тестах:
Co-discovery method
Teaching method
Coaching method
