И.А.Пономарев

Методы оценки качества

пользовательского интерфейса

Введение

В процессе проектировании программного обеспечения (ПО) для большинства современных операционных систем (ОС) с графическим интерфейсом пользователя (таких как Microsoft Windows, MacOS, различные варианты оболочек над XWindow в unix-системах) и  создании информационных систем на базе таких ОС, неизбежно встает вопрос о проектировании и разработки качественного пользовательского интерфейса.

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

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

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

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

Хотя оценка качества пользовательского интерфейса процесс достаточно субъективный и трудно формализуемый [1], можно с уверенностью утверждать, что хороший интерфейс должен обеспечивать эффективную и производительную работу пользователя.  Существует также и ряд критериев, которым должен удовлетворять качественный интерфейс [5, 6, 7, 8, 4]:

·       лучше тот интерфейс, при котором время выполнения задачи меньше;

·       лучше тот интерфейс, в котором число непроизвольных ошибок пользователя меньше;

·       неоднозначность в понимании интерфейса должна быть минимальна (это способствует самообучению пользователей и делает их поведение предсказуемым);

·       необходима высокая стандартизация интерфейса (она облегчает обучение пользователей);

·       объем вводимой пользователем информации должен стремиться к минимуму (одни и те же данные не должны вводиться несколько раз)

·       простота и визуальная привлекательность (удобство использования не менее важно, чем функциональность).

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

Можно выделить ряд наиболее распространенных методов оценки качества пользовательского интерфейса (рис. 1):

Рис. 1. Методы оценки интерфейса

Метод фокус-групп

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

Работа фокус-группы может как предварять количественные исследования, так и проводиться после них.

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

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

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

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

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

Рис. 2.  Типичное соотношение между числом проблемам (пожеланий) в различных группах пользователей

При этом вполне понятно, что в первую очередь нужно решать проблемы средних пользователей (так их абсолютное большинство) ­– рис. 2.

Полезно произвести несколько повторных оценок интерфейса (итераций) теми же фокус-группами уже после внесения в него изменений.

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

,

где :

– количество найденных ошибок, проблем и т.п. в интерфейсе

– количество проблем для которых предложено подходящее решение

– фактор продуктивности работы фокус группы

 – номер итерации

,

где:

– общее количество проблем, для которых предложено подходящее решение (за все итерации)

– общее количество проблем, для которых предлагалось повторное решение (за все итерации), т.е. таких, первоначальное решение для которых оказалось ошибочным или недостаточным

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

Опыт показывает [10], что в успешных проектах наиболее типична зависимость рис. 3.

Рис. 3. Типичная зависимость числа ошибок по итерациям

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

Прототипирование

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

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

Наиболее целесообразно применять этот подход на ранних этапах проектирования, что помогает выбрать правильное направление разработки, однако возможно и создание “локальных” прототипов для отдельных элементов пользовательского интерфейса. Таким образом данных подход охватывает как проектирование интерфейса как целого, так и проектирование его частей.

Для создания прототипов привлекают не только специалистов, но и конечных пользователей, при этом полезны любые мнения, предложения и графические наброски; основная задача – создать 5-7 вариантов интерфейса решающего одну и туже задачу. При создании прототипов нужно исходить из разумного баланса между следующими ключевыми факторами:

·       необходимый объем ресурсов для создания прототипа;

·       планируемое время жизни прототипа (предназначен ли он для решения краткосрочной, локальной проблемы или для длительного, глубокого анализа);

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

Созданные прототипы подвергаются сопоставительному анализу, в связи с чем необходимо определить критерии оценки. Отправной точкой в определении таких критериев служит та проблема, ради решения которой были созданы прототипы. Ей может быть время ввода данных пользователем, время принятие пользователем решения на основе предоставленной информации, субъективная оценка качества интерфейса по некоторой шкале и т.п. Как правило, наиболее эффективен сопоставительный анализ прототипов по нескольким методам: GOMS, Фокус-группы, Экспертная оценка.

Анализ задач

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

Для проведения тестирования нужно иметь несколько человек представляющих предполагаемый круг будущих пользователей системы [9], которые незнакомы с интерфейсом [4]. Исследования показывают, что нет необходимости проводить тестированием с большим числом пользователей, оптимальным число является 7-12 субъектов [9]. При таком небольшом числе пользователей можно обнаружить около 80% ошибок и неточностей в интерфейсе (неудачное расположение интерфейсных элементов, неудобное меню, непонятные надписи и т.п.) и получить при этом достоверный результат.

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

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

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

На основе полученных данных формируется отчетность:

·       Анализ портрета типичного пользователя.

·       Анализ продуктивности работы пользователя.

·       Оценка общего уровня удовлетворенности пользователей.

·       Наиболее часто встречающиеся замечания и жалобы пользователей.

·       Список приоритетных проблем (по числу жалоб пользователей и времени выполнения задачи).

Далее в рамках полученных данных идет работа по улучшению интерфейса.

Метод GOMS

GOMS это семейство методов позволяющих провести моделирование выполнения той или иной задачи пользователем и на основе такой модели оценить качество интерфейса (точнее говоря оценить время выполнения задачи как основной критерий качества) [2]. GOMS это сокращение от английского Goals, Operators, Methods, and Selection Rules – Цели, Операторы, Методы и Правила выбора. Данный способ был предложен S. K. Card, T. P. Moran и A. Newell в 1983 году.

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

В данном методе каждая цель или задача (Goal), которую хочет достичь пользователь с помощью интерфейса, состоит их набора методов (Methods) которые в свою очередь построены из операторов (Operators). Если цель может быть достигнута несколькими способами, то выбор осуществляться по правилам выбора (Selection Rules).

Простым примером может служить выбор пользователем пиктограммы на рабочем столе в графическом интерфейсе ОС Windows:

Операторы:

М – передвинуть указатель мыши в нужную точку (1.1сек);

П – перенос руки между мышью на клавиатурой (0.4сек);

К – нажать клавишу на клавиатуре (0.28сек);

Л – щелчок левой кнопкой мыши (0.1сек);

А – анализ дальнейших действий (1.2сек);

Задача: Выбрать пиктограмму.

Метод: Выбор с помощью мыши.

         К: нажать Win-D для перехода на рабочий стол;

         А: поиск пиктограммы находится на рабочем столе;

         П: перенести руку на мышь;

         М: переместить курсор в нужную точку;

         Л: выбор пиктограммы.

Формально метод GOMS может быть описан следующим способом:

 – множество операторов

 – оператор есть некое действие пользователя  и среднее время , затрачиваемое пользователем на это действие

 – множество целей (задач) которые пользователь выполняет с помощью имеющегося интерфейса

, где:

 – множество методов достижения цели

 – множество критериев выбора метода достижения цели

 – метод есть упорядоченный набор операторов, применяя которые достигается цель

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

Данный метод, как и любой другой, имеет свои преимущества и недостатки.

Преимущества метода:

·       простота и удобство расчетов;

·       отсутствие параметров в модели позволяет проводить оценочные сравнение двух разных вариантов интерфейса;

·       дает прогноз времени работы пользователя с данным вариантом интерфейса;

·       модель не требует создания рабочего прототипа;

·       анализ по этой модели может быть автоматизирован.

Наиболее заметными являются следующие ограничения:

·       метод ориентирован на средних пользователей, и не учитывает особенностей работы новичков и специалистов, а также индивидуальных различий пользователей;

·       метод не учитывает возникновение случайных ошибок в работе;

·       модель не учитывает, что в процессе работы происходит научение, а при простое – забывание;

·       модель не учитывает насколько представляемая интерфейсом информация сложна для понимания пользователем;

·       модель не учитывает насколько интерфейс отвечает требованиям пользователей и их ожиданиям.

Экспертная оценка

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

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

Перед проведением оценки эксперт составляет список правил в порядке их важности, которые должны быть соблюдены. В этот список входят как рекомендации поставщика ОС и инструментальных средств, так и наработанные в данной предметной области типовые решения. При оценке проверяют насколько тот или иной интерфейс соответствует списку требований.

Данный метод во многом полагается на опыт, компетентность и профессионализм проводящих анализ специалистов.

Экспертная методика оценки определена и в [ГОСТ 28195-89] и [ГОСТ Р ИСО/МЭК 9126-93]. Так, эти стандарты определяют показатели качества ПО и методики их оценки, данные показатели позволяют оценить качество ПО в целом, и в том числе удобство использования.

Так, [ГОСТ Р ИСО/МЭК 9126-93] вводит понятие практичности ПО – Набор атрибутов, относящихся к объему работ, требуемых для использования и индивидуальной оценки такого использования определенным или предполагаемым кругом пользователей.

А так же следующие характеристики практичности:

·       понятность (усилия пользователя по пониманию общей логической концепции ПО и ее применимости);

·       обучаемость (усилия пользователя по обучению применению ПО);

·       простота использования (усилия пользователя по эксплуатации и оперативному управлению ПО).

В соответствии с [ГОСТ Р ИСО/МЭК 9126-93] для ПО диалога конечного пользователя наиболее важны характеристики практичности, а пользователя могут интересовать следующие вопросы:

·       Имеются ли требуемые функции в программном обеспечении?

·       Является ли программное обеспечение удобным для использования?

·       Насколько эффективно программное обеспечение?

·       Насколько надежно программное обеспечение?

Основываясь на методике изложенной в [ГОСТ 28195-89] и используя современный набор характеристик качества по [ГОСТ Р ИСО/МЭК 9126-93] можно преложить следующую процедуру количественной оценки качества:

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

2. Назначаются количественные значения весовых коэффициентов  характеристик качества (они зависят от потребностей покупателей и сегмента рынка, на который ориентировано ПО), причем .

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

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

5. Определяются (по введенной шкале) количественные значения характеристик качества  анализируемого ПО.

6. Производится расчет взвешенной суммы (интегрального показателя качества): , где .

7. Качество ПО определяется путем сравнения полученного значения  с соответствующим базовым значением  и индивидуального сравнения с продуктами-аналогами

Уровень качества производимо ПО должен соответствовать базовому уровню и иметь потенциал для роста до предельно достижимого уровня.

Выводы

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

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

Литература

1. [A. Cooper, 2003]

2. [D. Kieras, 2002]

3. [Головач В.]

4. [Головач В., 2000]

5. [Microsoft Corporation, 2003].

6. [IBM Corporation, 2001]

7. [Apple Computer Corporation, 2002]

8. [Apple Computer Corporation, 2002]

9. [Торрес Р.Дж., 2002]

10. [Michael C. Medlock, 2002]

11. [Scott Berkun, 2000]

12. [ГОСТ 28195-89]

13. [ГОСТ Р ИСО/МЭК 9126-93]