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

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

Нередко тестирование требует от участников предварительного соглашения о неразглашении информации и подтверждения их согласия на запись хода и результатов тестирования.

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

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

При проведении тестирования главное – наблюдать за ходом мысли пользователей. Когда нет уверенности, что вам понятно, о чем они думают, можно спросить у них об этом. Например, если пользователь смотрит на экран в течение 10 с, можно спросить у него: на что вы смотрите или о чем вы задумались?»

Самая главная задача тестирования – понять, какие на каждом шагу у пользователей возникают ожидания и насколько программа соответствует этим ожиданиям. Если пользователь говорит: «Я не знаю, что делать дальше», вам нужно спросить: «А как вы думаете, что бы вы могли сделать?» или «А что бы вы сделали, если бы были дома?» Когда пользователь уже готов щелкнуть мышью, можно спросить у него, что он ожидает увидеть. После того как он щелкнет мышью, узнайте, действительно ли результат оправдал его ожидания.

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

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

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

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

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

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

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

• Каковы проблемы, с которыми сталкивались пользователи, и какие из них должны быть исправлены?

• Каковы возможные решения отобранных проблем?

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

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

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

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

Здесь мы кратко рассмотрим следующие методики тестирования:

• метод фокусных групп;

• проверку посредством наблюдения за пользователем;

• запись «мыслей вслух»;

• проверку качества восприятия;

• измерение производительности;

• карточную сортировку;

• RAFIV-метод.

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

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

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

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

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

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

По свидетельству А. Лебедева (www.artlebedev.ru/kovodstvo/126/), во многих известных компаниях не пользуются услугами фокус-групп, например в компании «Apple». Вместе с тем в маркетинге это одна из базовых стратегий, играющая роль универсального обоснования всякого решения.

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

Мыслим вслух. Запись или протоколирование «мыслей вслух» – очень распространенная методика, применяемая при юзабилити-тестирова-нии. Во время тестирования, пока участник выполняет то или иное задание в рамках своего сценария, экспериментатор просит его проговаривать мысли, чувства и мнения, возникающие в процессе взаимодействия с продуктом. Комментарии записывают, а затем анализируют. Здесь в первую очередь необходимо предоставить участнику сам тестируемый продукт (или прототип его интерфейса) и сценарий – список заданий, которые ему необходимо выполнить. Попросите участников в процессе выполнения заданий подробно сообщать все, что возникает у них в голове, пока они работают с интерфейсом продукта.

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

Эта методика очень дешевая, весьма информативная и может использоваться на любой стадии разработки ПИ.

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

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

Методика достаточно проста. Пользователю дается задание, связанное с каким-либо отдельным диалоговым окном. Он его выполняет. Через несколько минут его просят нарисовать (пускай даже грубо и некрасиво) только что виденное им окно. После этого рисунок сравнивается с оригиналом.

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

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

При измерениях производительности необходимо учитывать следующие моменты:

1. Критерий выполнения задачи должен быть количественно определен. Дело в том, что для измерения производительности необходимо, чтобы задачи имели четкий критерий в виде численно выраженной величины. К примеру, можно задаться вопросом: что более эффективно – кнопки на управляющей панели или «горячие» клавиши? Ответ на сформулированный таким образом вопрос можно получить при помощи тестирования двух интерфейсов: одного, ориентированного на «горячие» клавиши, а второго – на панели с кнопками. Производительность каждого пользователя определяется при помощи замеров времени, потраченного им на выполнение каждого задания, и допущенных пользователем ошибок.

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

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

По всем этим причинам измерение производительности используется на начальных этапах проектирования ПИ для задания контрольных замеров. Также оно используется на протяжении всего проектирования для измерения того, насколько далеко удалось продвинуться относительно этих контрольных замеров.

Измерение скорости работы производится с помощью системы GOMS (Goals, Operators, Methods and Selection Rules – цели, операторы, методы и правила их выбора).

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

Отметим, что полноценным российским аналогом метода GOMS является операционно-психофизиологический метод (ОПФ-метод), разработанный Г.М. Зараковским еще в конце 60-х годов прошлого века (подробнее см. в разд. 4.2).

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

Таблица 5.2

Среднее время некоторых типовых действий

На практике указанные значения могут варьировать в широких пределах. Для опытного пользователя, способного печатать со скоростью 135 слов/мин, значение К может составлять 0,08 с, для обычного пользователя, работающего со скоростью 55 слов/мин, – 0,2 с, для среднего неопытного пользователя, работающего со скоростью 40 слов/мин, – 0,28 с, а для начинающего – 1,2 с. Нельзя сказать, что скорость набора не зависит от того, что именно набирается. Для того чтобы набрать одну букву из группы случайно взятых букв, большинству людей требуется около 0,5 с. Если же это какой-то запутанный код (например, адрес электронной почты), то у большинства людей скорость набора составит около 0,75 символа в секунду. Значение К включает в себя и то время, которое необходимо пользователю для исправления сразу замеченных ошибок.

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

1. Операторы М следует устанавливать перед всеми операторами К, а также перед всеми операторами Р, предназначенными для выбора команд. Однако перед операторами Р, предназначенными для указания на аргументы этих команд, ставить оператор М не следует.

2. Если оператор, следующий за оператором М, является полностью ожидаемым, то этот оператор М может быть удален. Например, если вы перемещаете мышь с намерением нажать ее кнопку по достижении цели движения, то в соответствии с этим правилом следует удалить оператор М, устанавливаемый по первому правилу. В этом случае последовательность РМК превращается в РК.

3. Если строка вида МКМКМК принадлежит оперативной единице мышления, то следует удалить все операторы М, кроме первого. Оперативной единицей является непрерывная последовательность вводимых символов, которые могут образовывать название команды или аргумент. Например, Y, перемещать, Елена Троянская или 4567,34 являются примерами когнитивных единиц.

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

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

6. Любую часть оператора М, которая перекрывает оператор Р, учитывать не следует.

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

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

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

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

RAFIV -метод – это когнитивный метод юзабилити-тестирования, упрощенный и предназначенный для программистов и инженеров, не знакомых с основами когнитивной психологии. Он базируется на том, что большинство проблем ПИ связано с недостатками в представлении пользователю информации, которая должна последовательно помогать решать задачи (двигаться к цели), служить «поводырем», т.е. вести пользователя за собой. Метод предполагает анализ пять когнитивных этапов решения задач, первые буквы названия которых и образуют аббревиатуру RAFIV (Reformulate, Access, Format, Insert, Verify).

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

Таким образом, выделяют пять этапов выполнения задачи и определяют, какая когнитивная нагрузка требуется на каждом этапе. Эти пять этапов таковы:

1. Формулирование или переформулирование своих намерений (задачи, которую намеревается выполнить пользователь) в форме определенных характеристик объектов (Reformulate the task in terms of features and data).

2. Достижение требуемых характеристик объектов посредством меню, разного рода ссылок либо иных средств (Access the feature that will accomplish the task).

3. Приведение характеристик к виду, требуемому системой. Перед вво-

дом данных пользователь должен привести их к нужному виду (Format the data according to the system's requirements).

4. Ввод характеристик, приведенных к требуемому виду (Insert the formatted data into the system).

5. Получение информации о том, что данные были введены и правильно восприняты системой (Verify and monitor that data were entered correctly).

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

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

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

1. Используйте знания, как находящиеся в голове, так и находящиеся во внешнем мире.

2. Упрощайте структуру задачи.

3. Стремитесь визуализировать задачу, соединяя исполнение и оценку.

4. Отображайте структуру задачи.

5. Используйте мощь ограничений, естественных и искусственных.

6. Всегда предполагайте возможность ошибок.

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