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

Введение

Юзабилити тестирования — дорогое удовольствие. Традиционно тестирование проводится одновременно только с одним добровольцем, очевидно, что каждая такая сессия увеличивает общую цену тестирования. Единственный способ снизить цену — это проводить оптимальное количество сессий, т.е. достаточно большое, чтобы выявить большинство проблем, но такое чтобы цена оставалась приемлемой. Проблема определения оптимального числа участников привлекает к себе внимание на протяжении последних 15 лет и стала причиной множества дебатов среди практиков и теоретиков юзабилити. Мы не пытаемся изобрести колесо, а хотим продвинуть дискуссию дальше вопроса об "оптимальном количестве участников тестирования". Мы считаем, что в области юзабилити тестирований нужно сместить фокус с количества пользователей принимающих в них участие на тщательность разработки и количество задач — факторы имеющие решающее значение в исследованиях юзабилити. Чтобы доказать или опровергуть нашу гипотезу проанализируем результаты работы 9 команд участвовавших в CUE-4, обсудим полученные статистические результаты и дадим основанные на них рекомендации.

Условия исследования

Объем выборки

"Магическое число 5" так называлось одно из выступлений на конференции CHI 2003 претендующая на то, чтобы раз и навсегда решить вопрос об оптимальном объеме выборки для юзабилити тестирования. Число 5 вытекает из утверждений [16, 13] о том, что 5 пользователей достаточно для обнаружение 80% и 85% проблем в исследуемом интерфейсе, соответственно. Вирзи [16], применив процедуру Монте-Карло к результатам трех тестирований, показал асимптотическое отношение между количеством пользователей и долей обнаруженных проблем, которое может быть выражено следующей формулой:

Доля обнаруженных проблем = 1 - (1-p)n,

где p — вероятность обнаружения проблемы, а n — количество пользователей. Через год, используя распределение Пуассона и данные 5 тестирований и 6 эвристических исследований, Нильсен и Ландоер [14] пришли к похожей формуле,

Найденные(i) = N(1-(1-?)i),

где ? — вероятность обнаружения проблемы, N — общее количество проблем, а i — количество пользователей. Обе формулы позволяют определить необходимое количество пользователей при известных p или ? и предопределенной доле проблем которые должны быть обнаружены, к примеру, 0.85. Как показано в [14] для малых, средних и больших проектов оптимальное по цене количество пользователей 7, 15 и 20 соответственно, а 3.2 пользователя дают наилучшее отношение цены к качеству исследования. Нильсен утверждает, что при ? = 0.31, необходимо всего 5 пользователей чтобы обнаружить 85% проблем, это объясняет почему "сложные юзабилити тестирования пустая трата денег". Магическое число 5, было быстро адаптировано многими организациями как оптимальное количество пользователей для юзабилити тестирования, которое обеспечивает приемлемый уровень возврата инвестиций. Тем не менее, вскоре было обнаружено, что реальность очень отличается от заявленного, к примеру, Spool&Schroeder [15] сообщили, что первые пять пользователей в 49 тестах четырех коммерческих сайтов обнаружили только 35% проблем, показав значение ? равным только 0.082, в случае Faulkner [4] хорошо проработанное исследование показало, что 5 пользователей могут обнаружить менее 55% проблем. Значения ? в литературе колеблются от 0.08 до 0.51 [14, 15, 16]. Используя значение ? равное 0.31 во всех исследованиях, независимо от сложности интерфейса, можно столкнуться с переоценкой доли обнаруженных проблем и как следствие, недооценкой необходимого размера выборки.

Кроме предположения о значении ?, есть и другое предположение, которое может объяснить противоречивость результатов различных исследований. В формуле предполагается, что общее количество проблем в исследуемом интерфейсе известно, и равно общему количеству обнаруженных [16] или среднему количеству проблем обнаруженных в каждом тесте [14]. Но, серия исследований CUE [8, 10, 11, 12] показывает, что обнаружение "всех проблем" которые есть в интерфейсе, маловероятно. Исследования CUE-2 и CUE-4 обнаружили незначительное совпадение проблем обнаруженных различными командами при исследовании одного и того же интерфейса:

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

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

Не делая предположения о том, что нам известно общее число проблем или считая им число проблем обнаруженных в исследовании, Якобсен [7, упоминается в 6] предположил, что количество обнаруженных проблем пропорционально среднему геометрическому количества пользователей и исследователей.

Количество обнаруженных проблем = C ?(количество исследователей x количество пользователей).

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

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

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

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

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

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

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

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

Задачи исследования

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

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

Методология исследования

Основа исследования

Благодаря Рольфу Моличу, отчеты команд участвовавших в CUE-4 общедоступны [9].  Из 17 команд профессиональных юзабилити специалистов, 9 проводили юзабилити тестирования, и в общей сложности задействовали 76 пользователей, остальные использовали различные экспертные методы. Мы остановились на анализе исключительно юзабилити тестирований потому, что их параметры очень хорошо поддаются контролю:

  • Все команды использовавшие тестирования были высокопрофессиональными.
  • Все работали с одним и тем же сайтом.
  • Все использовали метод "думать вслух".
  • Исследования были проведены в одно и то же время.
  • Все получили одинаковые инструкции перед исследованием поэтому были схожи такие параметры тестирования как:
    • цели исследования
    • критерии проблемы
    • исследования были сфокусированы на системе резервирования OneScreen
    • пользовательские задачи от команды разработчиков, iHotelier (осуществляющих поддержку системы резервирования OneScreen), были наиболее интересными
    • формат отчетов

Мы использовали факторы которые не контролировались в оригинальном исследовании, а именно, размер выборки и количество пользовательских задач, как независимые переменные в нашем исследовании. Аргументами в пользу использования данных CUE-4 было то, что сайт Hotel Penn был и остается полнофункциональными коммерческим сайтом, а исследования имеют высокую достоверность и проведены профессионально.

Источники данных

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

Анализ данных

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

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

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

Количество пользователей используемых командой варьировалось от 5 до 15 и показано в таблице №1. В каждой сессии тестирования участвовал один пользователь, который вслух высказывал свои мысли. За исключением команды A в которой пары заказывали номера вместе в одной из 7 сессий.

Таблица №1: Количество пользователей в командах
Команда A H J K L M N O S
Пользователи 6 12 7 5 6 15 13 6 6

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

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

Команда A представила таблицу из 13 задач, с обоснованием выбора каждой задачи и анализом ее целей.

Команда H представила 9 задач без каких либо объяснений и анализа целей.

Команда J представила 6 сценариев, снабженных описанием результатов.

Команда K представила список из 12 задач, многие с краткой инструкцией или вопросом, но без сценариев, к примеру: "Есть ли свободные комнаты ночью 4 января 2004".

Команда L представила 10 задач, в основном, тех же самых, что и команда A, но две из них были модифицирована, а одна своя.

Команда M представила 10 сценариев с анализом целей, для каждой задачи были четко прописаны точка старта, точка завершения и критерии успеха.

Команда N использовала 4 задачи записанных в текстовом виде с заголовками, к примеру: "Семейные выходные в Нью-Йорке" (задача 1), "Заполнение формы предварительного заказа и бронирование комнаты" (задача 4).

Команда O использовала комбинацию из 16 задач и сценариев. Задачи 14, 15 и 16 выполнялись, если позволяло время.

Команда S давала пользователям легенду, чтобы они могли войти в роль и сценарий на 8 задач в текстовом виде.

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

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

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

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

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

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

Цель задачи: Зарезервировать

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

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

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

Классификация пользовательских задач.

Каждый сценарий и его описание были внимательно изучены и разделены на элементарные задачи, для каждой из которых было составлено описание. Некоторые задачи не требовали дальнейшего разделения. К примеру, 10 задача команды K: "Отменить сделанную вами резервацию на 5 мая", или 6 задача команды L: "Вы хотели оставить детей с братом, но подумали, что путешествие в Нью Йорк может им понравиться и решили взять их с собой. Сможете ли вы изменить сделанный предварительный заказ, на комнату для 4 человек? Обе эти задачи являются элементарными и не подлежат дальнейшему делению.

Задача 4 команды N, напротив была разбита на 5 элементарных задач, (1) заполнение формы резервации, (2) завершение резервации, (3) отказ от резервации, (4) переход к странице резервации, (5) изменение бронирования.

Задачи не связанные с сайтом Hotel Penn были исключены. К примеру, задача 6 команды J: "Используйте Интернет, чтобы найти отель Marriott, расположенный недалеко от Penn, и зарезервировать там комнату.

Каждая элементарная задача была распечатана, скреплена с примечанием и сгруппирована с близкими по смыслу, чтобы можно было объединить их в пользовательские задачи и определить цель задачи. К примеру, задача "Зарезервировать комнату для семьи из трех человек, с 28 июня по 5 июля" команды S и задача "Зарезервировать комнату для семьи из трех человек в июне" команды M были объединены в одну уникальную пользовательскую задачу, названную "резервирование семейной комнаты".

Результаты пользовательских задач

Многие задачи были не связаны с теми вопросами которыми интересовался iHotelier, но они важны для обнаружения проблем в интерфейсе OneScreen, поэтому мы включили их в анализ. В этой группе была 41 пользовательская задача, 21 из которых (51%) использовались только одной командой. Количество сценариев представленных каждой командой и количество пользовательских задач, можно увидеть в таблице 4.

Анализ обнаруженных проблем

В CUE-4 каждая команда должна была представить максимум 50 проблем и любых позитивных комментариев в виде таблицы заранее определенного формата с использованием системы кодирования из таблицы №2. Все проблемы пронумерованы по порядку, имеют детальное описание, и классифицированы в соответствии с инструкциями, некоторые команды предлагают возможные решения каждой проблемы. Чтобы избежать путаницы, при указании на проблему мы будем маркировать ее кодом команды, к примеру, M-17 указывает на проблему 17 из отчета команды M.

Таблица №2: Категории проблем
Категория Наименование Описание
C Позитивные находки Подход полезен и должен быть сохранен.
P Мелкие проблемы Заставили пользователей задуматься на несколько секунд
Q Серьезные проблемы Пользователи смогли преодолеть их в течении 1-5 минут. Редко приводят к полной неудаче.
R Критические проблемы Часто приводят к невозможности выполнения пользователем задачи или его значительному раздражению.
A Хорошие идеи Предложения пользователей позволяющие существенно улучшить их взаимодействие с сайтом.
T Баги Сайт работает не совсем так как предполагалось разработчиками. Это включает орфографические ошибки, неработающие ссылки, ошибки в скриптах и т.п.

Классификация проблем

Девять команд, проводивших юзабилити тестирования, обнаружили от 20 до 50 проблем, в общей сложности они сообщили о 348 проблемах.

Таблица №3: Количество проблем в отчетах команд
Команда A H J K L M N O S
Проблемы 50 50 20 27 36 50 30 50 35

Ознакомившись с отчетами команд, мы обнаружили множество комплексных проблем состоящих их нескольких более простых. Необходимо было составить один список из уникальных проблем категорий P, Q, и R. Этот процесс состоял из 6 шагов:

Шаг 1

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

Шаг 2: 0-я ступень группировки

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

Шаг 3: 1-я ступень группировки

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

Шаг 4: 2-я ступень группировки

Были пересмотрены результаты 1-ой ступени группировки. Помимо проблем они содержали позитивные находки, баги, полезные идеи. Вторая ступень группировки заключалась в создании отдельного списка их 200 проблем.

Шаг 5: Отбор

Позитивные находки (C), полезные идеи (A), баги (T) и проблемы не связанные с системой резервирования OneScreen, были удалены из списка после чего осталось 176 проблем, классифицированных как мелкие (P), серьезные (Q), и критические (R). После этого шага мы получили окончательный набор уникальный и релевантных проблем.

Шаг 6: Серьезность проблем

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

  1. Присваивали оригинальную категорию, в случае отстутствия конфликтов, к примеру P если для данной проблемы все команды выбирали P.
  2. Преобладающую, к примеру P в случае если команды выбирали P, P, P, Q
  3. Среднее значение, елси оно подходило, к примеру Q в случае если команды выбирали P, Q, R
  4. Там где конфликт не мог быть разрешен вышеперечисленными методами, мы присваивали проблеме категория исходя их таблицы 2.

В результате был составлен список из 70 (40%) мелких проблем и список из 106 (60%) серьезных или критичеких проблем. Данные из последнего списка использовались в нашем дальнейшем анализе.

Новые проблемы

Исследования Cockton & Woolrych’s [2] показали что дополнительные задачи в тестировании, помогают обнаружить новые проблемы. Мы глубже исследовали этот факт и разработали метод сравнения эффективности обнаружения новых проблем командами.

Для каждой команды мы считали базовыми данные остальных команд. Когда были составлены полные списки проблем обнаруженных каждой тестовой командой, мы смогли определить количество новых (не перекрывающихся с обнаруженными другими командами, уникальных) проблем обнаруженных каждой командой, и полное количество уникальных проблем обнаруженных всеми командами. Процент новых проблем обнаруженных командой равен: (количество новых проблем обнаруженных командой)/(полное количество проблем обнаруженных остальными командами). Результаты представлены в таблице №4.

Таблица №4: Результаты анализа пользовательских задач и найденные проблемы
Команда A H J K L M N O S
Количество пользователей 6 12 7 5 6 15 13 6 6
Количество задач 13 9 6 12 10 10 4 16 8
Количество пользовательских задач 14 11 5 11 12 10 6 10 8
Количество элементарных задач 15 13 5 11 12 11 6 11 9
Обнаружено проблем, % 42 43 7 22 27 29 23 24 30
% Новых проблем 12 8 0 4 4 3 2 5 4

Результаты

В среднем процент обнаруженных проблем 27.44 (SD = 10.85), а процент новых проблем 4.67 (SD = 3.50). Несмотря на то, что результаты команд A, H, и J значительно отклоняются от средних значений, они были включены в анализ поскольку данные CUE-4 отличаются высокой достоверностью, а все участвовавшие команды  очень профессиональны. А значит, при большем количестве команд, стоит ожидать большего количества похожих результатов.

Чтобы подтвердить или опровергуть взаимосвязь между исследуемыми величинами мы использовали критерий согласия Колмогорова-Смирнова. Результаты представлены в таблице 5.

Таблица №5: Коэффициенты корреляции
Параметр % обнаруженных проблем % новых проблем
Количество пользователей
нет существенной корреляции
нет существенной корреляции
Количество пользовательских задач
r = 0.731, p < 0.05
(n = 9)
r = 0.821, p < 0.01
(n = 9)
Количество элементарных задач
r = 0.823, p < 0.01
(n = 9)
r = 0.870, p < 0.005
(n = 9)

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

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


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

Охват задач

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

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


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


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


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

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

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

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

Результаты команды L (27%) были значительно хуже результатов команды A (42%) несмотря на то, что они использовали одинаковые задачи и по 6 пользователей каждая, именно из-за различий в стратегии рекрутинга. В соответствии с нашими критериями оценки качества рекрутинга, стратегия команды 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 не прослеживается закономерностей или трендов, которые могли бы свидетельствовать о том, что чем большей пользователей мы задействуем тем больше проблем будет обнаружено.

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

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

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

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

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

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

Будущие исследования

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

  1. Как влияют различные аспекты пользовательских задач, на результативность юзабилити тестирования, на количество и тип обнаруживаемых проблем?
  2. Какова роль стратегии рекрутинга и ее влиние на результативность тестирования?
  3. Какие факторы влияют на результативность юзабилити тестирования и какова их значимость?
  4. Зависят ли эти факторы один от другого?
  5. Если они взаимозависимы то каковы связи между ними?
  6. Какова роль вхождения пользователя в роль в юзабилити тестировании?

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

Выводы

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

Благодарности

Мы благодарим Рольфа Молича, оргинизаторов и участников CUE-4 за ценные данные, и всех кто помог ценными комментариями в процессе подготовки этого материала. Исследование было поддержано грантом NSERC/Cognos IRC Grant no: IRCSA23087-05. 

Литература

  1. Chattratichart, J. & Jordan, P. W. Simulating ‘lived’ user experience – Virtual immersion and inclusive design. In Proceedings of Interact 2003, Amsterdam:IOS Press (2003), 721-725.
  2. Cockton, G & Woolrych, A. Understanding inspection methods: Lessons from an assessment of heuristic evaluation. In People & Computers XV, A. Blandford& J. Vanderdonckt (Eds.), Springer-Verlag (2001),171-191.
  3. Constantine, L. CHI 2003 Feature: Testing… 1 2 3 4 5… Testing… http://usabilitynews.com/news/article1058.asp. May,2003.
  4. Faulkner, L. Beyond the five-user assumption:Benefits of increased sample sizes in usability testing.Behavior Research Methods, Instruments &Computers, 35, 3, Psychonomic Society (2003), 379-383.
  5. Fleiss, J. L. Statistical Methods for Rates and Proportions, 2nd Ed., John Wiley & Sons (1981).
  6. Hertzum, M. & Jacobsen, N. E. The evaluator effect:A chilling fact about usability evaluation methods.International Journal of Human-Computer Interaction, 15, 1, Lawrence Erlbaum Associates(2003), 183-204.
  7. Jacobsen, N. E., Hertzum, M., & John, B. E. The evaluator effect in usability studies: Problem detection and severity judgements. In Proc. HFES 1998, HFES(1998), 1336-1340.
  8. Molich, R. & Dumas, J. S. Comparative Usability Evaluation (CUE-4). Behaviour & Information Technology, Taylor & Francis (in press).
  9. Molich, R. & Jeffries, R. Comparative expert review,In Proc. CHI 2003, Extended Abstracts, ACM Press(2003), 1060-1061.
  10. Molich, R., Ede, M. R., Kaasgaard. K., & Karyukin,B. Comparative usability evaluation. Behaviour&Information Technology, 23, 1, Taylor & Francis(2004), 65-74.
  11. Molich, R., Bevan, N., Curson, I., Butler, S.,Kindlund, E., Miller, D., & Kirakowski, J.Comparative evaluation of usability tests. In Proc.UPA 1998, UPA (1998), 189-200.
  12. Molich, R., Thomsen, A.D., Karyukina, B., Schmidt,L., Ede, M., Oel, W.V. & Arcuri, M. Comparative evaluation of usability tests, Proc. CHI 1999,Extended Abstracts, ACM Press (1999), 83-84.
  13. Nielsen, J. Why you only need to test with 5 users, Jakob Nielsen’s Alertbox, March 19, 2000,http://www.useit.com/alertbox/20000319.html.
  14. Nielsen, J., & Landauer, T. K. A mathematical model of the finding of usability problems. In Proceedings of INTERCHI 1993, ACM Press (1993), 206-213.
  15. Spool, J. & Schroeder, W. Testing Websites: Five users is nowhere near enough. In Proc. CHI 2001,Extended Abstracts, ACM Press (2001), 285-286.
  16. Virzi, R.A. Refining the test phase of usability evaluation: How many subjects is enough? Human Factors, 34, HFES (1992), 457-468. CHI 2007 Proceedings • Usability Evaluation April 28-May 3, 2007 • San Jose, CA, USA

Похожие статьи