У меня периодически возникает закономерное желание узнать, какой софт удобнее, или доказать преимущество какого-нибудь продукта с помощью каких-то адекватных, численных аргументов (а не как обычно).
Заинтерисовавшись этой темой всерьез, я долго искала решения, и даже год назад написала и защитила дипломную работу «Определение количественной оценки качества взаимодействия человек-компьютер». О ней я и расскажу в статье.
Есть несколько способов определить удобство интерфейса.
Работающие методики
Анкетирование пользователей
Существует множество международно одобренных анкет (SUMI, SUS, SEQ, и др.), которые представляют собой спискок от 1 до бесконечности с вопросами вроде «Нашли ли вы эту систему сложной для себя». В тексте дипломной работы можно посмотреть обзор нескольких самых популярных систем.
Эксперименты на живых пользователях
Можно провести серию экспериментов с какими-то численными параметрами (например, скорость выполнения задачи, количество ошибок или средний уровень выполнения задач).
Эксперт
Можно пригласить какого-нибудь авторитетного дядьку и надеяться, что за свой 5/10/20-летний опыт он что-то такое узнал.
Но эти способы требуют нанять дорогого юзабилити-специалиста (или даже несколько), и выловить на улице пользователей.
Поэтому многие разработчики, в ужасе от перспективы взаимодействия с конечными пользователями, придумывали способы формальной оценки сложности системы.
Методики, которые не требуют участия специалиста или пользователей
* если интересно подробнее узнать про какую-то методику, обзор со ссылками на литературу есть в тексте диплома
Определение среднего времени необходимого пользователю по методике GOMS, KLM
На основе средних значений просто считают, сколько времени средний пользователь затратил бы на выполнение основных задач. Правда, непонятно, кто определяет, какие именно пользовательские сценарии просчитывать.
Энтропия RGB-профиля
Оценивается визуальная сложность системы. Очевидно, что программа с десятью панельками и двадцатью кнопочками, сложнее, чем стартовая страница гугл. Естественно, способ очень относительный, но простой и быстрый.
Информационная производетельность
Отношение минимального количества информации, необходимого для выполнения задачи, к количеству информации, которое должен ввести пользователь. Например, если выводится информационное модальное окно с единственной кнопкой «ОК», то вводимая пользователем информация (клик по кнопке) абсолютно бесполезна, что уменьшает показатель информационной производительности.
Не очень понятно, как определять необходима информация или нет для все более сложных случаев. Скорее всего, без эксперта тоже не обойтись.
Анализ XML-дерева
Чем сложнее код, описывающий интерфейс, тем, вероятно, сложнее для пользователя программа.
Очень спорное утверждение, скорее всего работает только для очень грубой оценки (фотошоп сложнее нотпада, так как кода больше).
Количество классов на которые можно разбить объекты интерфейса
На этом последнем, так коряво названном методе, я и остановилась.
Перед тем, как описывать суть метода, я сразу оговорюсь, что область применения его достаточно ограничена. Когда я только о нем узнала, он сиял сказочным светом, но в процессе работы над дипломом, как-то немного осунулся и сдулся. Скорее всего, применять такой метод можно для небольших виджетов-приложений, в которых можно более-менее выделить основные задачи и постоянные последовательности действий. Он не годится для творческих приложений с суперконтролом и неформализуемым результатом (фотошоп, автокад и т.д.)
Я базировалась на методике оценки сложности системы Тима Комбера и Джона Мэлтби, изложенной в работе Comber T., Maltby J.R. Investigating Layout Complexity; in Proc. CADUI, 1996.
Обозначим сложность системы C. В соответствии с теорией информационной энтропии Клода Шеннона, доработанной Джи Бонсипе сложность будет определяться по формуле
где N — количество всех объектов,
pi – отношения объектов в i-том классе ко всем объектам (pi =ni/n ),
n – количество классов объектов,
ni – количество объектов i-го класса,
Для использования в видео-дисплейных терминалах привяжем сложность к расположению и размерам объектов:
C = CS + CD,
где CS основана на классах-размерах объектов и CD на классах-взаимном расположении.
Сложность отдельного объекта:
CO = C/N
Конечно, это примитивный способ. Но это способ, который хоть как-то пытается распределить объекты по типу. Если кнопочки одинакового размера и стоят рядом, то все просто. Если все контролы разные, то функции, ими выполняемые, тоже скорее всего разнообразны и специфичны.
Исходный алгоритм предполагает оценку только одного, главного экрана приложения. Я буду оценивать сложность всей последовательности экранов, которые должен пройти пользователь, чтобы выполнить свою задачу. Для каждого экрана рассчитывается показатель сложности, при этом если при выполнении задачи некоторые элементы интерфейсса остаются постоянны, для них вводится понижающий коэффициент.
Чтобы сделать оценку более привязанной к жизни, я предложила ввести коэффициенты значимости пользователей и задач.
Пользователи разбиваются на несколько групп в зависимости от их нужд и выполняемых задач, для каждого типа пользователей задается коэффициент значимости.
Он зависит от:
— количества пользователей данного типа,
— частоты использования ими продукта,
— стоимости их времени или маркетинговой значимости данного типа.
Cuk — сложность системы для k-того типа пользователей
Ctn — сложность n-ной задачи
Ktn — коэффициент важности n-ной задачи для пользователя
После того, как мы получаем информацию о том, насколько сложно пользоваться интерфейсом каждой группе пользователей, мы можем вычислить итоговую сложность. Для этого нужно суммировать сложности для типов пользователей помноженные на весовые коэффициенты значимости пользователей.
Главное отличие такого подхода от исходной методики — мы опираемся на реальных людей с реальными нуждами. Программа не может быть абстрактно сложной, она может быть сложной для людей, чьи задачи не выполняет или выполняет долго, и перегружая ненужной информацией. По сути, понятие сложности переопределяется в соответствие задачам.
Вкратце
Итого, я взяла методику, которая определяла сложность интерфейса, замеряя, на сколько классов можно разбить все контролы и сколько контролов в каждом классе.
Предложила сначала выделить несколько типов пользователей, каждому, в зависимости от численности, частоты использования и стоимости времени, присвоить коэффициент.
Для каждого типа пользователей выделить задачи с разными коэффициентами значимости.
Для каждой задачи создать последовательность экранов и их уже считать по исходной методике.
В конце получается оценка, отражающая насколько интерфейс прост для выполнения конкретных задач релевантными пользователями.
Слабое место: выделять пользователей и задачи все равно надо самостоятельно. Но один раз разобравшись, какие типы пользователей и какие у них задачи, можно быстро и дешево считать насколько альтернативные версии хуже или лучше. Работает только для достаточно простых программ.
Полезность: получается не расплывчатый комментарий эксперта, а цифры, которые можно сравнивать.
- Даниляк В.И. Человеческий фактор в управлении качеством: инновационный подход к управлению эргономичностью: учебное пособие.– M. Логос, 2011. Мест — книга написана человеком, который занимался интерфейсом пульта управления самолетом, многовато воды, но попадается интересное
- Свиридов В. А. Человеческий фактор.– nafanin.deda.ru/human-factor/human-factor-spreads.pdf — дядька пишет про разработку систем управления самолетами. Информации не очень много, но как автобиография интересно и как-то трогательно что ли
- Randolph G. Bias, Deborah J. Mayhew Cost-Justifying Usability, Second Edition: An Update for the Internet Age, Second Edition.– Morgan Kaufmann, 2005. — про то, сколько стоит плохой интерфейс. Интересные статистические данные
- Stickel С., Ebner M., Holzinger A. The XAOS Metric – Understanding Visual Complexityas measure of usability.– Work &Learning, Life & Leisure, Springer, 2010, pp. 278-290 — про автоматическое определение сложности на основе количества и разнообразия контролов
- Bevan N. International Standards for HCI and Usability // International Journal of Human-Computer Studies.– 2001.– 55 (4) — все работы и идеи немного расплывчатые, но имя этого Бевана много где в ссылках встречается
- Bevan N. Measuring usability as quality of use // Journal of Software Quality Issue.– 1995.– 4, pp 115-140
- Sauro J. 10 Benchmarks For User Experience Metrics. – www.measuringusability.com/blog/ux-benchmarks.php — весь сайт интересный. Компания уже долго занимается тем, что пытается мерить юзабилити. Получается тоже не очень хорошо, но сам Сауро вроде бы публикует научные статьи и вообще в теме
В дипломной работе, кроме спецчасти есть вполне себе интересная часть с историями и байками про всякие ужасы, которые произошли из-за факапов в юзабилити, обзор статистики по финансовому урону, которые наносят дерьмовые интерфейсы и обзор всяких способов оценить юзабилити (заботливо, хоть и немного коряво, собранный и переведенный из десятка источников).
Можно посмотреть содержание, и если найдете что-нибудь интересное, скачать сам диплом.
1.1. Место эргономики в науке о качестве
1.2. Понятийный аппарат
1.3. Экономический эффект от повышения юзабилити
1.4. Экономический эффект
1.5. Влияние на безопасность
1.6. Примеры
1.6.1. Экономический эффект
1.6.2. Влияние на безопасность
Крушение рейса 965
Вывод из строя боевого корабля
Крушение дистанционно управляемых летательных аппаратов
Авиакатастрофа 1972 г.
Авария на Три-Мейл-Айленд АЭС
1.7. Потребность в оценке пользовательских свойств интерфейса. Вывод
2. Обзор литературы. Существующие решения для оценки эргономичности ПО
2.1. История развития стандартов эргономики интерфейса
ГОСТ 28195-89 Оценка качества программных средств. Общие положения
Стандарты ИСО
Вывод
2.2. Существующие критерии общей сертификации ПО
Отзывы от сертификационных лабораторий
Вывод
2.3. Существующие способы оценки эргономичности интерфейсов
2.3.1. Оценки основанные на сравнении и соответствии среде
Стандартизированность и соответствие рабочей среде
Бенчмаркинг
Примеры
2.3.2. Экспертная оценка
Эвристическая оценка
2.3.3. Анкетирование пользователей по итогам взаимодействия с системой
Общие требования. Респонденты
Сколько нужно респондентов
Анкета по словам
Лояльность пользователей (Net Promoter Score, NPS)
Software Usability Measurement Inventory, SUMI
System Usability Scale, SUS
Оценка сложности задач, базирующаяся на единственном вопросе
2.3.4. Количественные оценки базирующиеся на экспериментальных данных
Количество ошибок
Средний уровень выполнения задач
Объединенная метрика (Single Usability Metric, SUM)
Примеры
2.3.5. Формальные методы оценки
Информационный поиск
Информационная производительность
Модели KLM-GOMS
Оценка сложности системы Тима Комбера и Джона Мэлтби
XAOS — Actions, Organizational elements, Summed entropy of RGB values
LOC-СС модель измерения сложности
Примеры
2.4. Система менеджмента качества, как основа разработки эргономичного интерфейса
Идентификация заинтересованного лица
Опрос заинтересованных лиц
Сценарии использования
3. Разработка количественной оценки
3.1. Ограничения использования формальной численной оценки
3.2. Предварительные исследования. Участие экспертов
3.2.1. Источник данных. Требования к респондентам
3.2.2. Определение типов пользователей
3.2.3. Определение пропорций количества пользователей каждого типа
3.2.4. Оценка частоты использования
3.2.5. Определение стоимости времени пользоватей, либо их значимости с маркетинговой точки зрения
3.2.6. Калькуляция коэффициента значимости пользователя из полученных данных, либо присвоение коэффициента экспертом
3.2.7. Ранжирование задач для каждого типа пользователей
3.2.8. Выделение последовательности экранов, необходимой для решения задачи
3.3. Формальный расчет
3.4. Разбиение на классы
3.5. Пример расчета оценки
Исследование пользователей
Проверка
4. Экономическая часть
4.1. Построение календарного плана-графика
4.2. Построение алгоритма получения оценки взаимодействия человек-компьютер
4.3. Расчет затрат для получения оценки взаимодействия человек-компьютер
Вывод
6. Список литературы
Автор: limmm
