Юзабилити-тестирование: Что мы упустили?

1 июня 2008 г. • gitte-lindgaard

usability-bulletin Юзабилити Исследования Проектирование

Юзабилити-тестирование: Что мы упустили?

Нильсеновский постулат о «магическом числе пять» поставлен под сомнение. Джитт Линдгаард (Университет Карлтон, Канада) и Джарини Чаттратичарт (Университет Кингстон, Англия) опубликовали работу, которая объясняет, почему пятерка респондентов далеко не всегда обнаруживает «положенные» 85% ошибок – и, главное, как поправить дело.

Более десяти лет главная тема обсуждений между практиками и теоретиками, желающими повысить качество юзабилити-тестирования, - это количество участников. В данной статье мы представляем доказательства того, что фокус должен быть смещен на количество задач. Мы провели анализ результатов исследования CUE-4 и не выявили существенной связи между процентом выявленных проблем или количеством новых проблем, обнаруженных командой, и количеством пользователей, участвующих в тестировании. Зато выявлена сильная взаимосвязь этих значений и количества задач, используемых командой.

Мы пытались не изобрести колесо, а продвинуть дискуссию дальше вопроса об “оптимальном количестве участников тестирования”. Мы считаем, что в области юзабилити-тестирований нужно сместить фокус с количества пользователей, принимающих в них участие, на тщательность разработки и на количество задач — факторы, имеющие решающее значение в исследованиях юзабилити. Чтобы доказать или опровергнуть нашу гипотезу, мы проанализировали результаты работы 9 команд, участвовавших в исследовании CUE-4.

CUE датский проект по юзабилити интерфейсов. Несколько профессиональных юзабилити-команд независимо друг от друга проводят тестирование одного и того же ресурса или приложения, а затем сравнивают результаты.

Итак, «число пять» вытекает из утверждений Вирзи и Нильсена о том, что пятерых пользователей достаточно для обнаружения, соответственно, 80% и 85% проблем в исследуемом интерфейсе. Таким образом получается, что “сложные юзабилити-тестирования – пустая трата денег”. Многие сразу же восприняли число пять как оптимальное число пользователей для юзабилити-тестирования, которое обеспечивает приемлемый уровень возврата инвестиций.

Тем не менее, вскоре обнаружилось, что реальность очень отличается от заявленного: к примеру, Spool&Schroeder сообщили, что первые пять пользователей в 49 тестах четырех коммерческих сайтов обнаружили только 35% проблем. В случае Faulkner хорошо проработанное исследование показало, что пять пользователей могут обнаружить менее 55% проблем.

Однако есть предположение, которое может объяснить противоречивость результатов различных исследований. В формулах, которые использовали Вирзи и Нильсен, предполагается, что общее количество проблем в исследуемом интерфейсе известно, и что оно равно общему количеству обнаруженных или среднему количеству проблем, обнаруженных в каждом тесте. Но серия исследований CUE показывает, что обнаружение “всех проблем”, которые есть в интерфейсе, маловероятно. Исследования CUE-2 и CUE-4 обнаружили незначительное совпадение проблем, обнаруженных различными командами при исследовании одного и того же интерфейса:

CUE-2: 75% из 310 проблем были обнаружен только одной из команд; 8 команд исследовали один и тот же сайт, при этом было задействовано 53 пользователя.
CUE-4: 67% из 237 проблем были обнаружен только одной из команд; 9 команд исследовали один и тот же сайт, при этом было задействовано 76 пользователей.

Большой процент проблем, обнаруженных только одной из команд, наводит на мысль о том, что команды далеки от обнаружения “всех” проблем.

Задачи пользователей

Результаты юзабилити-тестирования зависят от многих факторов: подбор пользователей, задачи тестирования, проработка задач, критерии проблемы, навыки проводящих тестирование специалистов и т.п.

Тот факт, что различные команды исследователей находят различные проблемы, может быть объяснено различиями в пользовательских задачах. Исследование Hertzum & Jacobsen’s показало, что результативность исследований, использующих один из методов UEM (когнитивный анализ, эвристическое исследование, тестирование с привлечением пользователей) варьируется от 5% до 65%. Это происходит по причине неопределенности целей, процедур исследования и критериев проблемы.

В обзоре Hertzum & Jacobsen’s количество проблем, найденных исследователями, различалось в зависимости от различий в задачах: одни исследователи использовали экспертные методы, другие привлекали к тестированию пользователей, комментировавших свои мысли вслух.

Еще одно доказательство того, что различия в задачах могут быть важны, были получены Cockton & Woolrych. Для оценки одного и того же интерфейса проводились два юзабилити-тестирования, причем задачей второго было подтвердить опасения, появившиеся после первого. Различия в задачах привели к тому, что в процессе второго тестирования было выявлено несколько новых проблем.

Очевидно, что новые пользовательские задачи позволяют обнаруживать новые проблемы. К тому же в результате CUE-2 было обнаружено, что результаты работы команд в значительной степени различаются, в этом исследовании команды использовали 51 разную задачу, 25 из которых (49%) использовались только одной из команд. Молич комментировал этот так: “Количество задач может влиять на количество обнаруженных проблем. Тем не менее, оно не так существенно, как многие могли подумать”.

Мы решили ответить на два вопроса:

Существует ли взаимосвязь между количеством пользователей и долей обнаруженных проблем?
Существует ли взаимосвязь между количеством пользовательских задач и долей обнаруженных проблем?

Мы загрузили файлы по CUE-4 с сайта Рольфа Молича, в них содержатся отчеты всех 17 команд. Анализу подверглись 9 отчетов, представленных командами, проводившими юзабилити-тестирования; это были команды A, H, J, K, L, M, N, O, и S.

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

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

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

Очевидно, что количество задач, представленных в отчетах команд, не может быть проанализировано в чистом виде. По этой причине необходимо провести более детальный анализ задач:

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

Цель задачи: Найти комнату

Задачи пользователя:

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

Количество пользователей

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

[изображение] График №1: Взаимосвязь процента обнаруженных проблем и количества пользователей. [изображение] График №2: Взаимосвязь процента уникальных проблем и количества пользователей.

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

[изображение] График №3: Взаимосвязь процента обнаруженных проблем и количества пользовательских задач.

[изображение] График №4: Взаимосвязь процента уникальных проблем и количества пользовательских задач.

Информация о пользователях

Большинство команд предоставляли подробную информацию о пользователях, включавшую возраст, пол, опыт работы в Интернет, опыт онлайновых покупок, поиска, бронирования.

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

Результаты команды L (27%) были значительно хуже результатов команды A (42%) несмотря на то, что они были по шесть пользователей каждая и использовали одинаковые задачи. Это произошло именно из-за различий в стратегии рекрутинга. В соответствии с нашими критериями оценки качества рекрутинга, стратегия команды A была лучше стратегии команды L, поскольку пользователи, привлеченные командой A, были подходящими, а их группа разнородной. В то же время команда L не смогла выявить и исключить трех неподходящих пользователей.

Особенно неудачные результаты команды J можно объяснить сочетанием всех трех факторов: малое количество пользователей и задач, при этом все пользователи оказались экспертами, которые не раз использовали похожие сайты ранее.

Случай с командой O был неоднозначным. Пользователи, выбранные ими, активно путешествовали, но половина из них не имели опыта онлайнового бронирования. Это помогает объяснить, почему процент обнаружения уникальных проблем у этой команды был немного выше среднего, при посредственных общих результатах (24%).

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

Таблица №6: Данные о рекрутинге пользователей

КомандаРекрутингПримечаниеAХорошийХороший разброс в онлайновом опыте.HСреднийХороший разброс по опыту работы в Интернет. Все пользователи, кроме одного (разработчика ПО), имеют опыт онлайнового бронирования.JПлохойВсе пользователе эксперты в онлайновых покупках и ранее использовали подобные сайты. Два пользователя схожи по всем параметрам.KПлохойВсе кроме одного опытные пользователи Интернет. Один новичек, но с опытом онлайновых покупок. Один из пользователей – графический дизайнер.LПлохойХороший разброс опыта использования Интернет, но присутствуют веб-дизайнер, профессионал в области юзабилити и бывший менеджер отеля.MХорошийХороший разброс опыта использования Интернет.NПлохойВсе пользователи – эксперты и работают в IT-компании.OНеопределенноВсе пользователи интенсивно путешествовали. Часть из них не имеет опыта онлайнового бронирования. Данные недостаточные.SПлохойВсе эксперты.

Итоги

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

Все девять команд привлекали 5 или более пользователей. В соответствии с правилом пяти, должны быть обнаружены 85% проблем, а результаты работы команд не должны значительно различаться. На практике процент обнаруженных командами проблем варьировался от 7% до 43%, то есть был далек от 85%.

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

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

Интересен тот факт, что команда A (6 пользователей) и команда H (12 пользователей) показали одинаково хорошие результаты, обнаружив 42% и 43% процента проблем, при этом использовав 15 и 13 задач, соответственно. Чтобы проверить, может ли правило пяти считаться верным хотя бы в некоторых случаях, мы проверили, насколько перекрываются найденные ими проблемы. Оказалось, что 70% проблем, найденных этими двумя командами, обнаружены только одной из команд, из чего следует, что для имеющихся данных правило пяти неприменимо.

Команда M разработала одни из лучших тестов, задействовала много пользователей и подобрала большой набор задач, тем не менее, ее результаты хуже, чем у команд A и H. Результаты команды S, напротив, достаточно хороши, несмотря на то, что она не отличалась хорошим подбором или большим количеством пользователей, да и набор задач использовала небольшой. Однако это была единственная команда, которая помимо сценария давала пользователю легенду, чтобы он мог представить себя в новой роли. Благодаря этому пользователь выполнял задачи способом, близким к тому, как поступил бы реальный клиент. Это хорошо согласуется с выводами исследования, заключившего, что пользователи, которые пытаются вести себя в точности как целевые, позволяют провести более качественное исследование.

Статистические результаты позволяют утверждать: хороший подбор пользователей и широкий охват задач более продуктивны, чем увеличение числа пользователей. Эффективнее увеличить количество задач небольшой группе пользователей, чем задействовать больше пользователей при том же количестве задач. Таким образом, для оптимизации ROI юзабилити-тестирования нужно соблюдать баланс между количеством участвующих пользователей и количеством используемых в тестировании задач.

Статья публикуется в сокращении, полная версия (англ.)

Перевод: Евгений Абашкин, автор блога Design For Masters

Впервые опубликовано в «Юзабилити Бюллетень, выпуск 18».