Наблюдение за эмоциональными реакциями

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

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

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

При подготовке к тестированию необходимо выполнить ряд действий:

1. Выяснить общую цель исследований.

2. Разбить цель эксперимента на несколько чётких задач.

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

Социальные характеристики: пол, возраст, образование, должность, как часто пользователь работает на компьютере.

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

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

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

Профили пользователей помогут создать модель типового пользователя программного продукта - «персону». «Персона» — это описание конкретного пользователя, которого «выдумывает» коллектив, проводящий тестирование пользовательского интерфейса, на основе одного из профилей. Это помогает более рельефно представить себе типичного представителя какой-либо из пользовательских категорий.

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

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

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

Средний. Работа с компьютером является частью обычной (трудовой или личной) деятельности пользователя в течение двух лет или больше.

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

Очень низкий. Опыт использования компьютера малый, с резкими перерывами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отсутствие подсказок. По тексту задания не должно быть понятно, как это задание нужно выполнять.

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

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

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

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

7. Охарактеризовать требуемый персонал: понадобится как минимум один экспериментатор (ассистент), который будет проводить тестирование, начиная от оглашения его темы, объяснения плана тестирования и заканчивая непосредственной работой с участником тестирования над каждым заданием. Чтобы уменьшить нагрузку на экспериментатора, связанную с фиксацией получаемых данных, можно включить в состав команды одного или двух наблюдателей. Также во время тестирования должны присутствовать наблюдатели – участники проекта, имеющие непосредственное отношение к разработке программы и интерфейса.

8. Определить методику тестирования. Существуют следующие методики тестирования: метод фокусных групп, проверка посредством наблюдения за пользователем, «мыслим вслух», проверка качества восприятия, измерение производительности, карточная сортировка

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

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

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

«Мыслим вслух» - очень распространённая методика, применяемая при юзабилити-тестировании. Пользователю необходимо предоставить программный продукт (или прототип его интерфейса) и сценарий – список заданий, которые ему необходимо выполнить. Попросите участников в процессе выполнения заданий подробно сообщать всё, что возникает у них в голове, пока они работают с интерфейсом продукта. Комментарии записываются на диктофон или камеру, а затем анализируются. «Мысли вслух» позволяют понять, как пользователь подходит к интерфейсу и какими соображениями он руководствуется, используя этот интерфейс. Основную выгоду из использования данной методики заключается в лучшем понимании ментальной модели пользователя и его взаимодействия с программным продуктом.

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

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

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

Полученную в результате карточной сортировки информацию используют для организации и корректировки пользовательского интерфейса.

После окончания подготовки к тесту:

необходимо ввести пользователя в тестовую задачу;

выяснить у пользователя ожидания от программы;

протестировать интерфейс;

выяснить, насколько оправдались ожидания пользователя;

завершить тест.

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

При проведении тестирования интерфейса необходимо следовать следующим шести «никогда»:

1. Никогда не извиняться за несовершенство тестируемой системы.

2. Никогда не говорить, что все выявленные недостатки будут исправлены.

3. Никого не обвинять вслух в том, что пользовательский интерфейс составлен плохо.

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

5. Никогда не прерывать пользователя, когда он высказывает свое мнение о программе.

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

Кроме того, необходимо учитывать дополнительные рекомендации:

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

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

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

Если же юзабилити-специалист делает много наблюдений за работой пользователя, то рекомендуется пользоваться следующими тактиками:

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

Ошибки. В журнале тестирования ставить черточку при каждой пользовательской ошибке: мелкие черточки при несущественных ошибках и длинные – при ошибках серьезных. При этом рядом с черточкой необходимо проставлять букву, которая обозначает элемент интерфейса, при работе с которым произошла ошибка (например, «| M» - ошибка работы с меню). После теста необходимо систематизировать данные о количестве ошибок и их типу в зависимости от элемента интерфейса.

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

Эмоциональные реакции пользователя. Ставить в журнале тестирования знак «плюс» при положительных реакциях и знак «минус» – при отрицательных реакциях.

Во время тестирования не всякая ошибка пользователя объясняется ошибками интерфейса: пользователь может проявить элементарную невнимательность. Но все равно любая ошибка требует рассмотрения:

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

Если ошибка некритическая, т.е. пользователь сразу ее заметил и сам же ее исправил, то необходимо решение юзабилити-специалиста о ее исправлении. Исправлять проблему следует, если юзабилити-специалист чувствует, что понимает, почему ошибка произошла. Разумеется, если ошибка повторится, то ее необходимо устранить.

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

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

Необходимо принять к сведению предложения пользователей во время тестирования.

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

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

Анализ после тестирования лишен этих недостатков и достоинств. Он позволяет внимательно и вдумчиво проанализировать материал, независимо от количества и сущности измеряемых показателей.

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

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

Резюме (общее описание работы, номер версии программы, кто и когда проводил тест).

Основные ошибки (интерфейсные ошибки, проявляющиеся по всему интерфейсу).

Частные ошибки (ошибки, проявляющиеся на отдельных экранах).

Количественные данные (если они собирались).

Методика эксперимента и условия теста.

Описание тестовых сценариев.

Описание пользователей.

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

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

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

При написании этой части отчета соблюдайте следующие правила:

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

Недопустимы отступления от стандартного словаря терминов.

Когда речь идет о лицах, привлекаемых к тестированию программы, их называют «пользователь».

У английских наименований недопустима транскрипция на русском языке.

Для отражения количественных данных в отчете рекомендуется следующее:

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

Методика юзабилити-тестирования с использованием экспертных оценок

Крупный недостаток юзабилити-тестирования с привлечением группы пользователей – высокая стоимость. Одним из методов снижения стоимости тестирования является экспертная оценка. Экспертной оценкой называется определение проблем интерфейса через его оценку профессиональным дизайнером интерфейса или юзабилити-специалистом (экспертом).

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

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

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

Часть подготовительной работы у тестирования группой пользователей и у экспертной оценки одинакова.

Виды экспертной оценки:

проверка по контрольному списку;

эвристическая оценка;

мысленная прогонка по интерфейсу.

Поиск по сайту: