Юзабилити испытание: будто мы недооцениваем?

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

Введение

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

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

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

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

Доля найденных заморочек = 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] сказали, будто 1-ые 5 юзеров в 49 исследованиях 4 платных страниц нашли лишь 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 нашли незначимое совпадение заморочек найденных разными командами при изыскании 1-го и такого ведь интерфейса:

CUE-2: 75% из 310 заморочек были найден лишь одной из команд; 8 команд изучили 1 и тот ведь интернет-сайт, при данном было задействовано 53 юзера [10]. CUE-4: 67% из 237 заморочек были найден лишь одной из команд; 9 команд изучили 1 и тот ведь интернет-сайт, при данном было задействовано 76 юзеров [8]. Большой процент заморочек найденных лишь одной из команд, наводит на идею о том, будто команды далеки от обнаружения "всех" заморочек, а следственно волшебное количество 5 существенно преуменьшено.

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

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

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

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

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

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

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

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

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

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

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

Две основных темы изучения — это воздействие объема подборки и численности пользовательских задач, на итоги изучения. став заинтересованным вышеописанными связями меж плодами изучения и объемом подборки либо задачками, мы приняли решение ответствовать на 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.

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

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

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

проанализированы задачки юзеров и сценарии,

проанализированы трудности, о каких докладывала любая команда.

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

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

Таблица №1: численность юзеров в командах

Команда A H J K L M N O S

Пользователи 6 12 7 5 6 15 13 6 6

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

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

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

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

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

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

Команда L предположила 10 задач, в главном, тех ведь самых, будто и бригада A, однако 2 из их были изменена, а 1 своя.

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

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

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

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

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

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

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

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

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

проверить вразумительность горницы данного вида в определенный день,

проверить вразумительность горницы на последующий год,

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

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

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

зарезервировать помещение для некурящих,

зарезервировать домашнюю комнату,

зарезервировать помещение особенного типа.

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

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

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

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

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

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

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

Многие задачки были никак не соединены с теми вопросцами коими увлекался 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

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

Шаг 1

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

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

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

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

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

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

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

Шаг 5: Отбор

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

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

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

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

Преобладающую, к образцу P в случае ежели команды избирали P, P, P, Q

Среднее смысл, елси оно подходило, к образцу Q в случае ежели команды избирали P, Q, R Там в каком месте инцидент никак не имел возможность существовать допустим перечисленными выше способами, мы присваивали дилемме группа исходя их таблицы 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: взаимозависимость процента найденных заморочек и численности пользователей.

Охват задач

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

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

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

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

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

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

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

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

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

Особенно плохие итоги команды J, разрешено разъяснить сочетанием всех 3-х причин: маленькое численность юзеров и задач, при данном все юзеры специалисты, которые никак не раз употребляли схожие веб-сайты ранее.

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

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

Команда Рекрутинг Примечание

A

Хороший

Хороший разброс в онлайновом опыте

H

Средний

Хороший разброс по эксперименту работы в веб. Все юзеры не считая 1-го (разработчика ПО) имеют эксперимент онлайнового бронирования.

J

Плохой

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

K

Плохой

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

L

Плохой

Хороший разброс эксперимента применения веб, однако находятся веб-дизайнер, специалист в области юзабилити и былой клерк отеля.

M

Хороший

Хороший разброс эксперимента применения Интернет.

N

Плохой

Все юзеры специалисты и персонал IT-компании.

O

Неопределенно

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

S

Плохой

Все эксперты.

Обсуждение

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

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

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

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

Интересен тот прецедент будто бригада A (6 пользователей) и бригада H (12 пользователей) проявили идиентично отличные итоги, заприметив 42% и 43% процента заморочек, и применяв 15 и 13 задач, поэтому. 28%. чтоб испытать, имеет возможность ли верховодило 5-ти сообразовываться преданным желая бы в неких вариантах мы выяснили как перекрываются отысканные ими трудности. оказывается, будто 70% заморочек, найденных данными 2-мя командами, выявлены лишь одной из команд, из что надлежит, будто для наличествующих этих верховодило 5-ти никак не конструктивно. Команда M придумала одни из наилучших исследований, использовала немало юзеров и выбрала великий комплект задач, тем никак не наименее её итоги ужаснее нежели у команд A и H. итоги команды S, против, довольно неплохи, невзирая на то, будто она никак не различалась неплохим подбором либо огромным численностью юзеров, правда и комплект задач употребляла никак не великий, однако это была единственная бригада, коия кроме сценария, выдавала юзеру басню, чтоб он имел возможность доставить себя в новейшей роли. Благодаря данному, юзер исполнял задачки методом недалёким к тому, как поступил бы настоящий заказчик. Это отлично согласуется с заключениями изучения, заключившего, будто юзеры которые пробуют новости себя в точности как целевые, разрешают вести наиболее высококачественное изучение [1]. набивается суд, будто интерес к составным частям при исследованию сценария испытания и пользовательских задач, отбор юзеров и их численность никак не имеет возможность вполне турнуть огромного разброса результатов.

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

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

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

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

Какова роль стратегии рекрутинга и её влиние на действенность тестирования?

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

Зависят ли данные причины 1 от другого?

Если они взаимозависимы то каковы взаимосвязи меж ними?

Какова роль вхождения юзера в роль в юзабилити тестировании?

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

Выводы

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

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

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

Литература

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. 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. Constantine, L. CHI 2003 Feature: Testing… 1 2 3 4 5… Testing… http://usabilitynews.com/news/article1058.asp. May,2003. 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. Fleiss, J. L. Statistical Methods for Rates and Proportions, 2nd Ed., John Wiley & Sons (1981). 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. 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. Molich, R. & Dumas, J. S. Comparative Usability Evaluation (CUE-4). Behaviour & Information Technology, Taylor & Francis (in press). Molich, R. & Jeffries, R. Comparative expert review,In Proc. CHI 2003, Extended Abstracts, ACM Press(2003), 1060-1061. Molich, R., Ede, M. R., Kaasgaard. K., & Karyukin,B. Comparative usability evaluation. Behaviour&Information Technology, 23, 1, Taylor & Francis(2004), 65-74. 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. 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. 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. Nielsen, J., & Landauer, T. K. A mathematical model of the finding of usability problems. In Proceedings of INTERCHI 1993, ACM Press (1993), 206-213. Spool, J. & Schroeder, W. Testing Websites: Five users is nowhere near enough. In Proc. CHI 2001,Extended Abstracts, ACM Press (2001), 285-286. 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