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

http://www.techsmith.com/morae.asp

Это то, что отчасти использовала Microsoft, когда потратили миллионы на переработку Office 2007 с ленточной панелью инструментов.

Вот как был проанализирован Office 2007: http://cs.winona.edu/CSConference/2007proceedings/caty.pdf

Обязательно ознакомьтесь со ссылками в конце PDF-файла, там много хороших вещей. Посмотрите, как Microsoft сделала Office 2007 (независимо от того, как вы к этому относитесь), они потратили на это кучу денег.

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

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

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

У Якоба Нильсена есть достойная (короткая) статья на своем веб-сайте. Есть еще один, но он больше связан с тем, как тестировать, чтобы быть репрезентативным, а не как провести само тестирование.

Рассмотрите возможность измерения времени для выполнения критических задач (с использованием нового пользователя и опытного пользователя) и количества ошибок ввода данных для выполнения этих задач.

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

Затем возьмите две камеры, несколько пользователей (5-10) дадут им список задач, которые нужно выполнить, и попросят их подумать вслух. Половина пользователей должна использовать «старую» систему, остальные - новую.

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

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

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

Вы можете изучить модель GOMS (цели, операторы, методы и правила выбора) . На мой взгляд, это очень сложный исследовательский инструмент, но он дает «математическую» основу для измерения производительности в строго контролируемой среде. Лучше всего использовать с "опытными" пользователями. См. Это очень интересное тематическое исследование проекта Ernestine для New Телефонные операторы Англии.

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

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

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

Некоторые конкретные меры, на которые вы могли бы обратить внимание:

• Измерение времени на часах для стандартной задачи хорошо, если вы хотите знать, что занимает много времени. Однако лабораторные тесты обычно предполагают, что испытуемые работают намного усерднее и концентрируются гораздо больше, чем в повседневной работе, поэтому сравнение лабораторных результатов с результатами реальных пользователей будет вводить в заблуждение.
• Частота ошибок: как часто пользователь делает ошибки или отступает. Особенно, если вы замечаете, что одна и та же ошибка возникает снова и снова.
• Появление обходных путей; Если ваши пользователи работают над какой-либо функцией или предпринимают кучу шагов, которые вы считаете глупыми, это может быть признаком того, что ваш интерфейс не предоставляет инструментов для выяснения того, как решить их проблемы.
• Не стоит недооценивать, просто спрашивая пользователей, насколько хорошо, по их мнению, все прошло. Субъективное удобство использования привередливо, но может показаться откровенным.