Текст книги "Человеко-компьютерное взаимодействие"

1. Стремитесь к последовательности (непротиворечивости).

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

3. Предлагайте информативную обратную связь.

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

5. Предлагайте ПИ, предотвращающий ошибки, и простой путь их исправления.

6. Предусматривайте легкую отмену действия и возврат назад.

7. Поддерживайте контроль, расположенный внутри системы.

8. Сокращайте нагрузку на кратковременную (активную) память пользователя.

Особенно много весьма показательных ошибок в ПИ в Интернете, в дизайне web-страниц. Их рассмотрение можно найти по адресам:

http://hci.psychology.ru/Articles/10_Errors.doc

http://www.lboro.ac.uk/eusc/index_r_guides.html

http://www.usethics.ru/lib/krug/index.shtml

http://www.usethics.ru/lib/future_ui/index.shtml

http://www.webclub.ru/

http://citforum.ru/index.html и др.

Контрольные вопросы

1. Каковы цели оценки ПИ и условия, в которых они могут производиться?

2. Каковы достоинства и недостатки оценок в лабораторных условиях и в условиях реальной работы?

3. Состав и содержание методов оценок, основанных на анализе мнений экспертов, и оценок, основанных на участии пользователей.

4. Состав и содержание аналитических методов оценки.

5. Состав и содержание экспериментальных методов оценки и методов на основе анкетирования.

6. Состав и содержание методов наблюдений.

7. Физиологические параметры, измеряемые при оценке ПИ, их значение и методы регистрации.

8. Состав критериев оценки ПИ.

9. Методы оценки скорости работы пользователя и пути увеличения скорости работы.

10. Субъективная длительность действий и способы ее уменьшения.

11. Основные направления усилий по снижению ошибок пользователя и отражение таких усилий в характеристиках ПИ.

12. Стиль и формы сообщений пользователю о его ошибках.

13. Метафоры в ПИ, их роль, преимущества и недостатки, примеры метафорических дизайнерских решений в ПИ.

14. Роль стандартов и языка шаблонов в ПИ, правила описания шаблона.

15. Принципы интуитивной понятности ПИ.

16. Виды обучающих материалов, их классификация.

17. Спиральность текста справки, роль и способы реализации.

18. Основные составляющие субъективной удовлетворенности пользователя. Содержание восьми «золотых правил» Б. Шнейдермана.

19. Основные принципы и правила создания эстетической привлекательности ПИ.

20. Пути снижения уровня психической напряженности пользователя.

Литература

Основная

1. Вятчин К. Язык шаблонов в дизайне взаимодействия. http://www.usethics. ru/lib/ui_templates/index.shtml

2. Торрес Р. Дж. Практическое руководство по проектированию и разработке пользовательского интерфейса. – М.: Вильямс, 2002.

3. Рейнбоу В. Компьютерная графика. – СПб.: Питер, 2004.

4. Tidwell J. Pattern Language for Human-Computer Interface Design, 1999.

5. О'Квин Д. Допечатная подготовка. Руководство дизайнера. – М.: Вильямс, 2002.

6. Robson С. Experiment, Design and Statistics in Psychology. 3rd ed. – Penguin, 1994.

7. Wharton C., Rieman J., Lewis C., Poison P. The cognitive walkthrough: a practitioner's guide // J. Nielsen and R. L. Mack (Eds). Usability Inspection Methods. – John Wiley, 1994.

8. Nielsen J. Heuristic evaluation // J. Nielsen and R. L. Mack, (Eds.), Usability Inspection Methods. – John Wiley, 1994.

9. http://www.akzhan.midi.ru/iarchitect/mfame.htm

10. http://www.akzhan.midi.ru/iarchitect/mshame.htm

11. Norman D. The Design of Everyday Things. Publ. Currency/Doubleday; Reissue ed., 1990.

Дополнительная

12. Дедков В. Adobe Photoshop. Настольная книга мастера. – М.: Компьютерпресс, 2001.

13. Харовас П., Кундерт-Гиббс Д., Ли П. Maya complete. Уроки мастерства. – М.: ДМК Пресс, 2001.

14. Carroll J.M. HCI Models, Theories, and Frameworks: Toward a Multidiscip-linary Science (Morgan Kaufmann Series in Interactive Technologies). – Virginia Tech. Univ., 2003.

15. http://www.lboro.ac.uk/eusc/index_r_guides.html

16. Ojakaar E. Users Decide First; Move Second. Published: Oct 25, 2001. http:// HYPERLINK «http://www.uie.com/articles/users_decide_first/»www.uie.com/articles/users_decide_first/

17. Duchowski T. Eye Tracking Methodology: Theory and Practice. – Springer– Verlag, 2003.

18. Shneiderman B. Designing the User Interface: Strategies for Effective Human-Computer Interaction. 3rd еd. – Addison-Wesley, 1998.

19. Rich А., Shores R., McGee M. (Oracle Corp.) Expected usability magnitude estimation. Proc. of the Human Factors and Ergonomics Society. – 48th Annual Meeting, 2004.

20. http://hci.psychology.ru/Articles/10_Errors.doc

21. http://www.lboro.ac.uk/eusc/index_r_guides.html

22. http://www.usethics.ru/lib/krug/index.shtml

23. http://www.usethics.ru/lib/future_ui/index.shtml

24. http://www.webclub.ru/

25. http://citforum.ru/index.html

ТЕМА 5. ЮЗАБИЛИТИ-ТЕСТИРОВАНИЕ И ПРОТОТИПИРОВАНИЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

Изучаемые вопросы:

• Понятие юзабилити-тестирования.

• Цель юзабилити-тестирования.

• Базовые характеристики юзабилити-тестирования (согласно стандарту ISO 9241).

• Состав и содержание метрик юзабилити.

• Таксономия юзабилити.

• Подготовка и проведение юзабилити-тестирования.

• Анализ данных юзабилити-тестирования.

• Методики юзабилити-тестирования.

• Контрольные списки, их содержание и место в тестировании ПИ.

• Этапы разработки ПИ и их содержание.

• Принципы разработки ПИ.

• Содержание работ по формированию ПИ на каждом из этапов его разработки.

• Требования к прототипу на разных этапах разработки ПИ.

• Четыре версии прототипа, их характеристики, сравнительный анализ.

• Основные программные средства создания прототипов презентационной, псевдореальной и реальной версий.

• Необходимость письменного объяснения дизайнерских решений ПИ.

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

5.1. Юзабилити-тестирование ПИ

5.1.1. Понятие и таксономия юзабилити-тестирования ПИ

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

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

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

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

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

Стандарт по человеко-компьютерному взаимодействию ISO 9241 включает в себя три базовые характеристики юзабилити:

1) эффективность – можете ли вы сделать то, что хотите;

2) требуемые усилия (легкость) – можете ли вы сделать это без излишних усилий;

3) субъективная удовлетворенность – доставляет ли вам удовольствие процесс «делания».

Этими характеристиками должен быть описан любой конкретный показатель системы, как регламентировано в том же стандарте (табл. 5.1).

Таблица 5.1

Количественные измерения четырех показателей юзабилити по трех базовым характеристикам

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

1. Время выполнения задачи.

2. Процент выполненных задач.

3. Процент выполненных задач за определенное время.

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

5. Время, потраченное на обнаружение и исправление ошибок.

6. Процент или количество ошибок.

7. Процент или количество участников, показавших более высокие результаты, чем рассматриваемый.

8. Число произведенных действий.

9. Частота использования помощи или документации.

10. Процент благоприятных/неблагоприятных отзывов пользователя.

11. Число повторений неудавшихся действий.

12. Число успешных и неуспешных задач или их составных частей.

13. Сколько раз интерфейс вводил пользователя в заблуждение?

14. Число хороших и плохих элементов интерфейса, которые вспом-

нил пользователь.

15. Число невостребованных (но доступных) действий.

16. Число возвратов назад в действиях.

17. Число пользователей, отдавших предпочтение вашей системе.

18. Сколько раз пользователи сталкивались с неясной ситуацией, для решения которой они были вынуждены тратить время?

19. Сколько раз пользователи отрывались от работы?

20. Сколько раз пользователи утрачивали контроль над системой?

21. Сколько раз пользователи выражали удовлетворение (либо неудовлетворение, раздражение) от работы с системой?

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

1) разрабатываемый или предшествующий вариант ПИ;

2) вариант(ы) ПИ в конкурирующей(их) системе(ах);

3) характеристики выполнения задачи без разрабатываемого ПО;

4) абсолютная шкала;

5) ваш собственный прототип;

6) значения метрик юзабилити в предшествующих вариантах и/или аналогах;

7) значения метрик юзабилити при выполнении каждой отдельной задачи;

8) структурирование различия между лучшими и худшими значениями метрики юзабилити на основе анализа деятельности пользователей.

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

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

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

Попытка создания более полной таксономии показателей, составляющих понятие юзабилити, предпринята специалистами корпорации «Oracle». На основе того же стандарта ISO 9241 и многочисленных публикаций на эту тему выделены 64 показателя, затем методами факторного и кластерного анализа экспертных оценок были оценены вес каждого показателя и величины их взаимных связей. Это позволило ранжировать такие показатели и представить их в виде иерархической структуры, групп разных уровней. При этом степень близости между показателями, входящими в группы нижнего уровня, наибольшая, сами же такие группы объединены как целое также по близости с другими группами и т.д. по иерархии уровней объединения (рис. 5.1).

На рис. 5.1 по горизонтальной оси расположены величины расстояний между показателями, таким образом, чем больше расстояние, тем меньше степень близости. Величины расстояний (linkage distance) от 1 до 3 образуют первую группу; от 4 до 6 – вторую группу; от 7 до 9 – третью группу; от 10 до 14 – четвертую; от 15 до 25 – пятую. Все группы разделены на две большие области: юзабилити и неюзабилити. В области юзабилити выделены 3 степени близости показателей к этому понятию: основная (или стратегическая) юзабилити – 1-я группа; вторичная (или тактическая) юзабилити – 2-я группа; третичная (общая) юзабилити – 3-я группа.

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

2. Вторичная, или тактическая, юзабилити определяется следующими понятиями: эффективностью, степенью знакомства, контролируемостью, завершенностью, полезностью.

3. Третичная, или общая, юзабилити ассоциируется с такими понятиями, как ожидаемость, естественность, гибкость и релевантность, дружественность.

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

Рис. 5.1. Таксономия юзабилити с величинами ассоциативных связей

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

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

Результаты исследований позволили предложить следующее определение юзабилити: «Юзабилити есть восприятие того, насколько согласован, эффективен, продуктивен, организован, легок в использовании, интуитивен и прост интерфейс».

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

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

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

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

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

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

При создании нескольких простых страниц-эскизов дайте паре ваших пользователей опробовать их. Сделали простой прототип? Представьте его группе из нескольких пользователей. Такой подход к делу позволяет вносить изменения тогда, когда они наименее затратны. Гораздо проще изменить что-то фломастером на белой доске, нежели в готовом эскизе; легче изменить эскиз, чем прототип; и, наконец, легче изменить прототип нежели готовый продукт; по некоторым данным, соотношение затрат как 1:10:100.

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

Юзабилити-тестирование очень важно в процессе разработки ПИ, поэтому мы рассмотрим его подробно.

5.1.2. Подготовка к тестированию

Прежде всего при тестировании надо очень ясно поставить вопрос тестирования, причем в терминах, позволяющих однозначно ответить, является ли полученный результат ответом на этот вопрос. Возможно, вас интересует, почему после выхода последней версии продукта участились звонки в службу техподдержки. Или ваше положение на рынке пошатнулось, и вы желаете знать, не вызвано ли это тем, что продукция конкурента более удобна в использовании. Примером плохой постановки задачи может служить такая постановка: «Удобен ли мой продукт?». Хорошая постановка задачи могла бы выглядеть так: «Насколько сложной для новичка является процедура заполнения налоговых форм с помощью данного продукта? Предоставляет ли онлайн-система подсказки достаточное количество информации о налоговом кодексе? Эта информация изложена простым, доступным для понимания языком, а не на юридическом жаргоне?».

Перед тестированием надо отчетливо понимать характеристики потенциальных пользователей, которые и должны стать участниками тестирования. Это необходимо, потому что когда вы займётесь непосредственно подбором участников, очень важно будет знать, кто именно вам нужен: новички, эксперты или опытные пользователи, мужчины, женщины, или же вы нуждаетесь в представителях обоих полов; также важен возраст пользователей. Кто является целевой группой пользователей вашего продукта? Если вы тестируете дисплеи реактивных истребителей, вам ни к чему пропускать через ваши тесты толпы тинэйджеров. Если ваш продукт – автомат для продажи газировки, в таком случае те же ти-нэйджеры придутся как нельзя кстати. Как было сказано в разд. 3, основная работа по выявлению характеристик (профилей) пользователей делается ещё на этапе постановки задачи. Подробнее описание моделей пользователей приведено в разд. 3.

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

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

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

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