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

Александр Белышкин, 20.01.2008

Vlad Golovach
Usethics ⭕ doc
5 min readJun 24, 2015

--

В статье приводится метод сравнительной оценки качества интерфейса для продуктов, функциональность которых совпадает лишь частично.

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

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

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

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

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

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

Описать этот подход проще всего на примере. Рассмотрим процедуру сравнительного тестирования на примере трех видов программных калькуляторов (приведенный пример исследования — условный и не является описанием реального исследования). Назовем их: Калькулятор №1, Калькулятор №2, Калькулятор №3. Наборы функций у них отличаются. И отличия, как это обычно бывает, касаются функций, не самых распространенных среди обывателей (непрофессиональных пользователей калькулятора). Функции сравниваемых калькуляторов перечислены в следующей таблице. Знаком «•» отмечена функциональность, реализованная в продукте.

Таблица 1. Функциональность сравниваемых продуктов

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

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

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

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

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

  • Очень важно
  • Скорее важно
  • Средней важности
  • Скорее не важно
  • Совсем не важно.

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

Результаты опроса респондентов приведены в Таблице 2. Респонденты распределились следующим образом (первые 8 — бухгалтеры; 9–12 — школьники, 13–16 — инженеры). Для того что бы усреднить оценки значимости функциональности, полученные при опросе пользователей, используем медиану (число, являющееся серединой множества чисел), а не среднее.

Таблица 2. Результаты оценки респондентами важности отдельных функций

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

Таблица 3. Расчет мощности системы

Уже на этом этапе собранные данные мы можем использовать для того, чтобы сделать выводы относительно сравнения функциональности всех трех калькуляторов. Мы видим, например, что Калькулятор №1 существенно уступает конкурентам на нашей выборке респондентов из-за отсутствия функций % и sqrt, а производитель Калькулятора №2 заметно выиграл, избавившись от мало востребованных тригонометрических функций и добавив на первый взгляд ненужные x^2 и x^3, которые являются лишь частным случаем другой уже реализованной функции x^n. Однако наша цель — возможность сравнения количественных метрик, собранных в ходе тестирования. Используя полученные значения мощности, выведем коэффициент, который в дальнейшем можно будет использовать для этой цели.

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

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

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

--

--