Как измерить интерфейс. Количественный критерий

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

Заинтерисовавшись этой темой всерьез, я долго искала решения, и даже год назад написала и защитила дипломную работу «Определение количественной оценки качества взаимодействия человек-компьютер». О ней я и расскажу в статье.

Есть несколько способов определить удобство интерфейса.

Работающие методики

Анкетирование пользователей

Существует множество международно одобренных анкет (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 — количество всех объектов,
p_i – отношения объектов в i-том классе ко всем объектам (pi =ni/n ),
n – количество классов объектов,
n_i – количество объектов i-го класса,

Для использования в видео-дисплейных терминалах привяжем сложность к расположению и размерам объектов:
C = C_S + C_D,
где C_S основана на классах-размерах объектов и C_D на классах-взаимном расположении.

Сложность отдельного объекта:
C_O = C/N

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

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

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

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

C_uk — сложность системы для k-того типа пользователей
C_tn — сложность n-ной задачи
K_tn — коэффициент важности n-ной задачи для пользователя

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

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

Вкратце

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

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

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

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