Время от времени у меня возникает естественное желание узнать, какой софт удобнее, или доказать преимущество продукта с помощью каких-то адекватных, числовых аргументов (а не как обычно).
Серьезно заинтересовавшись этой темой, я долго искал решение и даже год назад написал и защитил кандидатскую диссертацию «Определение количественной оценки качества взаимодействия человека с компьютером».
Об этом я расскажу в статье.
Существует несколько способов определить удобство использования интерфейса.
Техники работы
Опрос пользователей
Существует множество одобренных на международном уровне опросников (SUMI, SUS, SEQ и т. д.), которые представляют собой список от 1 до бесконечности с вопросами типа «Нашла ли вы для себя эту систему сложной».
В тексте дипломной работы вы можете увидеть обзор нескольких наиболее популярных систем.
Ээксперименты на живых пользователях 
Вы можете провести серию экспериментов с некоторыми числовыми параметрами (например, скоростью выполнения задания, количеством ошибок или средним уровнем выполнения задания).
Ээксперт 
Можно пригласить какого-нибудь авторитетного парня и надеяться, что за свой 5/10/20-летний опыт он научился чему-то подобному.
Но эти методы требуют найма дорогого юзабилити-специалиста (а то и нескольких) и ловли пользователей на улице.
Поэтому многие разработчики, напуганные перспективой взаимодействия с конечными пользователями, придумали способы формальной оценки сложности системы.
Методы, не требующие участия специалиста или пользователей.
* если вы заинтересованы подробнее узнать о той или иной методике, обзор со ссылками на литературу находится в тексте диплома Определение среднего времени, необходимого пользователю методом ГОМС, КЛМ Основываясь на средних показателях, они просто подсчитывают, сколько времени среднестатистический пользователь потратит на выполнение основных задач.
Правда, непонятно, кто определяет, какие пользовательские сценарии рассчитывать.
Энтропия профиля RGB Оценивается визуальная сложность системы.
Очевидно, что программа с десятью панелями и двадцатью кнопками сложнее стартовой страницы Google. Естественно, метод весьма относительный, но простой и быстрый.
Информационная продуктивность Отношение минимального объема информации, необходимого для выполнения задачи, к объему информации, который должен ввести пользователь.
Например, если отображается информационное модальное окно с единственной кнопкой «ОК», то информация, введенная пользователем (нажатием на кнопку), является абсолютно бесполезной, что снижает показатель информационной продуктивности.
Не очень понятно, как определить, необходима ли информация или нет для все более сложных случаев.
Скорее всего, без специалиста тоже не обойтись.
Анализ XML-дерева Чем сложнее код, описывающий интерфейс, тем сложнее будет программа для пользователя.
Очень спорное утверждение, скорее всего оно работает только для очень грубой оценки (Фотошоп сложнее блокнота, так как там больше кода).
Количество классов, на которые можно разделить объекты интерфейса Я остановился на этом последнем методе с таким неуклюжим названием.
Прежде чем описать суть метода, сразу оговорюсь, что область его применения весьма ограничена.
Когда я впервые о нем узнал, он сиял сказочным светом, но в процессе работы над дипломом как-то немного осунулся и сдулся.
Скорее всего, этот метод можно использовать для небольших приложений-виджетов, в которых можно более или менее идентифицировать основные задачи и постоянные последовательности действий.
Не подходит для творческих приложений с супер контролем и неформализуемым результатом (Photoshop, AutoCAD и т.п.
) Я основывался на методе оценки сложности системы Тима Комбера и Джона Молтби, изложенном в работе Комбера Т.
, Малтби Дж.
Р.
Investigating Layout Complexity; в Proc. КАДУИ, 1996.
Обозначим сложность системы через C. В соответствии с теорией информационной энтропии Клода Шеннона, модифицированной Джи Бонсайпом, сложность будет определяться по формуле 
где N — количество всех объектов,
п я – отношения объектов i-го класса ко всем объектам (pi = ni/n),
n – количество классов объектов,
н я – количество объектов i-го класса,
Для использования в терминалах видеодисплея мы будем связывать сложность с расположением и размером объектов:
С=С С +С Д ,
где С С на основе классов размера объектов и C Д о классно-взаимном расположении.
Сложность отдельного объекта: С О = С/Н Конечно, это примитивный метод. Но это метод, который хоть как-то пытается распределить объекты по типам.
Если кнопки одинакового размера и расположены рядом, то все просто.
Если все элементы управления разные, то и функции, которые они выполняют, тоже, скорее всего, разнообразны и специфичны.
Оригинальный алгоритм предполагает оценку только одного — главного экрана приложения.
Я буду оценивать сложность всей последовательности экранов, через которые пользователь должен пройти, чтобы выполнить свою задачу.
Для каждого экрана рассчитывается показатель сложности, и если некоторые элементы интерфейса при выполнении задачи остаются постоянными, для них вводится понижающий коэффициент. Чтобы оценка была более связанной с жизнью, я предложил ввести коэффициенты важности пользователя и задачи.
Пользователи делятся на несколько групп в зависимости от их потребностей и выполняемых задач, для каждого типа пользователей устанавливается коэффициент значимости.
Это зависит от: — количество пользователей данного типа, - частота использования ими продукта, — стоимость их времени или маркетинговая значимость этого типа.
С Великобритания — сложность системы для k-типа пользователей
С ТН — сложность n-й задачи
К ТН — коэффициент важности n-й задачи для пользователя
Как только мы получим информацию о том, насколько сложен интерфейс для использования каждой группой пользователей, мы сможем рассчитать общую сложность.
Для этого нужно суммировать трудности по типам пользователей, умноженные на весовые коэффициенты важности пользователя.
Основное отличие этого подхода от оригинальной методологии заключается в том, что мы полагаемся на реальных людей с реальными потребностями.
Программа не может быть абстрактно сложной, она может быть сложной для людей, задачи которых она не выполняет или требует много времени, а также перегружать ненужной информацией.
По сути, концепция сложности пересматривается, чтобы соответствовать вызовам.
Кратко
Итак, я использовал технику, которая определяла сложность интерфейса путем измерения того, на сколько классов можно разделить все элементы управления и сколько элементов управления было в каждом классе.Она предложила сначала выделить несколько типов пользователей и присвоить каждому коэффициент в зависимости от количества, частоты использования и стоимости времени.
Для каждого типа пользователей подбирайте задачи с разными коэффициентами значимости.
Для каждой задачи создайте последовательность экранов и посчитайте их по оригинальному методу.
В конце получается оценка, отражающая, насколько удобен интерфейс для выполнения конкретных задач соответствующими пользователями.
Слабое место: вам все равно придется выбирать пользователей и задачи самостоятельно.
Но как только вы поймете, какие типы пользователей и какие у них задачи, вы сможете быстро и дешево подсчитать, хуже или лучше альтернативные версии.
Работает только для достаточно простых программ.
Полезность: результат — не туманный комментарий эксперта, а цифры, которые можно сравнивать.
Ссылки (сокращенно, без лишней ерунды)
- Даниляк В.
И.
Человеческий фактор в управлении качеством: инновационный подход к управлению эргономикой: учебник.
– М.
Логос, 2011. Мест - книгу написал человек, который работал над интерфейсом панели управления самолетом, многовато воды, но есть кое-что интересное
- Свиридов В.
А.
Человеческий фактор.
– nafanin.deda.ru/human-factor/human-factor-spreads.pdf — пишет парень о разработке систем управления самолетом.
Информации не много, но как автобиография интересно и как-то трогательно что ли
- Рэндольф Г.
Биас, Дебора Дж.
Мэйхью.
Экономически оправданное удобство использования, второе издание: обновление для эпохи Интернета, второе издание.
– Морган Кауфманн, 2005 г.
– о цене плохого интерфейса.
Интересная статистика
- Стикель С.
, Эбнер М.
, Холцингер А.
Метрика XAOS – понимание визуальной сложности как меры удобства использования.
– Work & Learning, Life & Leisure, Springer, 2010, стр.
278-290 – об автоматическом определении сложности на основе количества и разнообразия элементов управления.
- Беван Н.
Международные стандарты HCI и юзабилити // Международный журнал человеко-компьютерных исследований.
– 2001. – 55 (4) - все работы и идеи немного расплывчаты, но имя этого Бевана фигурирует во многих ссылках.
- Беван Н.
Измерение юзабилити как качества использования // Журнал Software Quality Issue.– 1995.– 4, стр.
115-140.
- Сауро Дж.
10 тестов для показателей пользовательского опыта.
– www.measuringusability.com/blog/ux-benchmarks.php - весь сайт интересный.
Компания уже давно пытается измерить удобство использования.
Тоже не очень получается, но сам Сауро вроде научные статьи публикует и вообще в теме
Вы можете просмотреть содержимое, и если найдете что-то интересное, скачать сам диплом .
Содержание диплома 1. Введение 1.1. Место эргономики в науке о качестве 1.2. Понятийный аппарат 1.3. Ээкономический эффект от повышения удобства использования 1.4. Ээкономический эффект 1,5. Влияние на безопасность 1.6. Примеры 1.6.1. Ээкономический эффект 1.6.2. Влияние на безопасность Крушение рейса 965 Выведение из строя военного корабля Крушение самолета с дистанционным управлением Авиакатастрофа 1972 года Несчастный случай на острове Три почты AЭS 1.7. Необходимость оценки пользовательских свойств интерфейса.
Заключение 2. Обзор литературы.
Существующие решения для оценки эргономики программного обеспечения 2.1. История развития стандартов эргономики интерфейса ГОСТ 28195-89 Оценка качества программного обеспечения.
Основные положения стандарты ИСО Заключение 2.2. Существующие критерии общей сертификации программного обеспечения Отзывы сертификационных лабораторий Заключение 2.3. Существующие методы оценки эргономичности интерфейсов 2.3.1. Оценки на основе сравнения и соответствия окружающей среде Стандартизация и соответствие рабочей среде Бенчмаркинг Примеры 2.3.2. Ээкспертная оценка Эвизуальная оценка 2.3.3. Опрос пользователей на основе их взаимодействия с системой Общие требования.
Респонденты Сколько респондентов необходимо? Анкета по словам Лояльность пользователей (Net Promoter Score, NPS) Инвентаризация измерения юзабилити программного обеспечения, SUMI Шкала удобства использования системы, SUS Оценка сложности задачи на основе одного вопроса 2.3.4. Количественные оценки на основе экспериментальных данных Количество ошибок Средний уровень выполнения задачи Единый показатель юзабилити (SUM) Примеры 2.3.5. Формальные методы оценки Поиск информации Информационная продуктивность Модели КЛМ-ГОМС Оценка сложности системы Тима Комбера и Джона Молтби XAOS — Действия, Организационные элементы, Суммарная энтропия значений RGB Модель LOC-CC для измерения сложности Примеры 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. Ссылки Теги: #интерфейсы #Юзабилити #интерфейс #оценка #количественная оценка #рейтинг
-
Остин, Джон Лэнгшоу
19 Oct, 24 -
Карты В Вашем Проекте
19 Oct, 24 -
В Сша С Кузовным Цехом: Ехать Или Не Ехать?
19 Oct, 24 -
Angular2 Теперь Является «Бета-Версией».
19 Oct, 24
