Юзабилити-тестирование: пошаговая инструкция на примере Yelp. Алгоритм юзабилити-тестирования

Акция: до конца месяца бесплатно сделаем юзабилити-аудит вашего сайта и дадим рекомендации по внедрению с 15% скидкой. Заказать юзабилити аудит сайта у экспертов Market Mentor.
С английского языка usability переводится как «удобство и простота использования, степень удобства использования». Другими словами - это удобство использования, пригодность использования, эргономичность - способность продукта быть понимаемым, изучаемым, используемым и привлекательным для пользователя в определенных условиях.

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

Почему юзабилити так важно?

Показатель юзабилити напрямую влияет на конверсию сайта.

В интернет-сфере данный критерий является необходимым условием:

Если сайт сложно использовать – посетитель его закроет.

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

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

Если информацию на сайте сложно воспринять и прочесть, или она не отвечает на ключевые вопросы – посетитель его закроет.

Главное правило электронной коммерции: если пользователь не может найти товар – он не сможет его купить.

Как люди воспринимают информацию в Интернете?

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

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

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

Что такое юзабилити (usability)?

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

Исследования User Interface Engineering, Inc показывают, что в 60% случаях люди не могут найти информацию в вебе, которая им нужна. Это приводит к потере времени, снижению производительности труда, а также к тому, что пользователи больше не вернутся на сайт.

Другие источники говорят:

· Forrester Research получил цифры, которые показывают, сколько теряют компании из-за плохого юзабилити сайтов. Интернет-магазины теряют порядка 50% покупателей, которые не могут найти нужный товар. Около 40% пользователей не возвращаются на сайт, с которым имели негативный опыт работы.

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

В чем отличие между разработкой юзабилити (Usability Engineering) и тестированием юзабилити (Usability Testing)?

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

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

Юзабилити-тестирование

Материал из Википедии - свободной энциклопедии

Проверка эргономичности (Юзабилити-тестирование, англ. Usability testing) - исследование, выполняемое с целью определения, удобен ли некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения. Таким образом, проверка эргономичности измеряет эргономичность объекта или системы. Проверка эргономичности сосредоточена на определённом объекте или небольшом наборе объектов, в то время как исследования взаимодействия человек-компьютер в целом - формулируют универсальные принципы.

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

Виды юзабилити тестирования

Пригодность к использованию и удобство веб-сайтов (web usability) изучается при помощи большого количества специальных методов:

Макетирование (Prototyping)

Обзоры (Surveys)

Опросники (Questionnaires)

Эвристическое исследование (Heuristic Evaluation)

Экспертиза компонентов (Feature Inspection)

Карточная сортировка (Card Sorting)

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

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

Контекстное исследование (Contextual Inquiry)

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

1. Учет контекста, в котором используется изучаемый сайт.

2. Совместная оценка сайта пользователем и разработчиком.

3. В фокусе оценки сайта находится именно его удобство для пользователя.

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

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

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

Подробности: H. Beyer and K. Holtzblatt. Apprenticing with the Customer: A Collaborative Approach to Requirements Definition

Контрольные листы (Checklists)

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

Макетирование (Prototyping)

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

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

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

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

Обзоры (Surveys)

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

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

Опросники (Questionnaires)

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

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

Подробности: J Kirakowski, PhD. The Use of Questionnaire Methods for Usability Assessment.

Плюралистическая проработка (Pluralistic Walkthroughs)

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

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

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

Протоколы самоотчета (Self-Reporting Logs)

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

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

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

Обычно эта техника используется на ранних стадиях планирования или разработки или для выявления пользовательских предпочтений.

Фиксация «мыслей вслух» (Thinking Aloud Protocol)

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

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

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

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

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

Фокусные группы (Focus Groups)

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

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

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

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

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

Когда начинать работать над юзабилити сайта?

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

Вот несколько обязательных условий для достижения верных показателей оценки юзабилити разных этапов создания сайта:

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

Проведите оценку сайтов конкурентов – это довольно хороший (а главное – бесплатный!) способ получить конкурентоспособные данные, которые помогут сделать сайт лучше ЧЕМ у конкурентов.

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

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

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

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

Проведите тестирование ЕЩЁ РАЗ напоследок, после того, как все-все-все правки были внесены, сайт уже начал свою «новую» жизнь. Потому что самые коварные проблемы могут появиться как раз после того, как появился «самый оптимальный» вариант интерфейса.

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

Процесс

При испытании многих продуктов пользователю предлагают в «лабораторных» условиях решить основные задачи, для выполнения которых этот продукт разрабатывался, и просят высказывать во время выполнения этих тестов свои замечания.

Процесс тестирования фиксируется в протоколе (логе) и/или на аудио- и видеоустройства - с целью последующего более детального анализа.

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

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

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

1. Речь модератора и респондента;

2. Выражение лица респондента (снимается на видеокамеру);

3. Изображение экрана компьютера, с которым работает респондент;

4. Различные события, происходящие на компьютере, связанные с действиями пользователя:

Перемещение курсора и нажатия на клавиши мыши;

Использование клавиатуры;

Переходы между экранами (браузера или другой программы).

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

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

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

A/B-тестирование

От англ. A/B testing, Split testing) - метод маркетингового исследования, суть которого заключается в том, что контрольная группа элементов сравнивается с набором тестовых групп, в которых один или несколько показателей были изменены, для того, чтобы выяснить, какие из изменений улучшают целевой показатель. Разновидностью A/B-тестирования является многовариантное тестирование. В этом случае тестируются не два целостных варианта, а сразу несколько элементов продукта или составных частей исследуемого объекта в различных сочетаниях, при которых каждый тестируемый элемент может быть двух видов (A или B).

Метод часто используется в веб-дизайне, типичные применения - исследование влияния цветовой схемы, расположения и размера элементов интерфейса на конверсию сайта. В веб-дизайне часто тестируются две очень похожие веб-страницы (страница А и страница В), которые различаются лишь одним элементом или несколькими элементами (тогда метод называют A/B/n-тестированием). Страницы А и В показываются различным пользователям в равных пропорциях, при этом посетители, как правило, не знают об этом. По прошествии определенного времени или при достижении определённого статистически значимого числа показов, сравниваются числовые показатели цели и определяется наиболее подходящий вариант страницы. Преимуществом метода является использование при проектировании объективных данных.

Для A/B-тестирования веб-дизайна часто используются инструменты от сервисов веб-статистики; в этом случае также часто важно применение механизма для разбиения пользователей, которым будет показан тот или иной вид дизайна (одному и тому же пользователю нужно показывать тот же самый вариант дизайна), например, на основе IP-адреса и затем установкой HTTP cookie.

Оценки удобства использования

Существует два основных способа оценки удобства (пригодности) использования продукта:

· прямая оценка на основе анализа результативности, эффективности и удовлетворённости, достигнутых в результате эксплуатации продукта в реальных условиях: если в указанных условиях одна система более эргономична, чем другая, то оценка должна это выявлять;

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

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

Косвенная оценка рассматривается в стандарте ISO/IEC 25010, который описывает следующие подхарактеристики удобства использования:

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

изучаемость (learnability): степень эффективности, производительности и удовлетворенности пользователя обучением использованию системы;

управляемость (operability, controllability): обеспечение простоты управления и контроля;

защищенность от ошибок пользователя (user error protection): степень, в которой система защищает пользователя от совершения ошибок;

эстетика пользовательского интерфейса (user interface aesthetics): степень, в которой пользовательский интерфейс удовлетворяет пользователя и доставляет ему удовольствие от процесса взаимодействия;

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

Важно ли юзабилити?

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

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

Важно обращать внимание на:

простоту использования сайта или интерфейса

эффективность использования

запоминаемость

ошибки, их количество и серьезность

удовлетворение пользователя (субъективное)

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

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

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

Известный дизайнер Якоб Нильсен предложил набор из 10 эвристик, или принципов проектирования взаимодействия.

Видимость статуса системы

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

Соответствие между системой и реальным миром

Система должна «говорить на языке пользователя», используя понятную ему терминологию и концепции, а не «системно-ориентированный» язык.

Управляемость и свобода для пользователя

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

Согласованность и стандарты

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

Предотвращение ошибок

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

Распознавать лучше, чем вспоминать

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

Гибкость и эффективность использования

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

Эстетический и минималистический дизайн

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

Помочь пользователю понять и исправить ошибку

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

Справка и документация

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

Правила и приемы юзабилити

Навигация

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

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

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

размещать подробную контактную информацию не только в «подвале» (самом низу страницы), но и в шапке сайта;

делать меню первого уровня на всех страницах;

указывать на веб-страницах название раздела сайта;

предусмотреть "хлебные крошки".

Внутренний поиск

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

Чтобы поиск на сайте был удобным, необходимо:

размещать его в верхнем правом углу на всех страницах;

ограничить длину поля для ввода запроса 27-30 символами (оптимальное значение);

сделать поиск исключительно внутренним, только по страницам ресурса. Не стоит предлагать посетителям еще и внешний поиск, по сторонним сайтам в Интернете – это будет отвлекать их от вашего;

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

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

Главная страница

Лишний раз говорить о значимости главной страницы не будем – это и так всем известно.

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

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

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

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

Оформление текста

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

Текст должен быть короткими и содержательными.

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

Для написания текста используйте простые и наиболее распространенные шрифты размера не меньше 12 px и без засечек – они лучше всего воспринимаются.

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

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

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

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

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

Юзабилити дизайн:

Красивый дизайн:

Основная задача – создание привлекательного внешнего вида Интернет-проекта, ориентируясь на конкретные пользовательские визуальные предпочтения.

Минусы: достижения ИТ отходят на второй план и мало взаимодействуют с общей концепцией usability; степень удовлетворенности от визуальной оценки имеет тенденцию к резкому понижению за счет недоработок в плане совместимости и технической базы проекта.

Плюсы: запоминающееся оформление веб-сайта.

Удобный дизайн:

Основная задача – достижение максимального уровня accessibility веб-сайта за счет устранения барьера несовместимости между технической комплектацией разработчиков и потребителей.

Минусы: Вынужденное ограничение дизайнерских решений.

Плюсы: Максимальный охват пользовательской аудитории, доступность и простота использования.

Альтернативный дизайн:

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

Минусы: Угроза попадания «в зависимость» от устоявшихся стандартов в дизайне или постоянного создания альтернативного дизайна.

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

Подведем итог

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

1. Сайт должен быть действительно нужен посетителю;

2. Интерфейс сайта не должен мешать пользователю совершить целевое действие и получить то, что он хочет.

Вот краткая формула для выявления практичности вашего сайта:

Полезность сайта - обладает ли сайт ответами на ваши вопросы.

Юзабилити - насколько легко и удобно управлять сайтом.

Практичность сайта = юзабилити + полезность.

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

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

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

Какими знаниями мы будем делиться?

• обзоры инструментов аналитики и A/B – тестирования,
• опыт и кейсы российских и зарубежных компаний по повышению конверсии,
• приемы улучшения юзабилити и секреты пользовательских интерфейсов,
• UX-исследования, инсайты и аналитика,
• интервью и вебинары с экспертами рынка.

Ну а теперь ближе к теме.

Что такое юзабилити-тестирование и в чем его польза?

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

Для крупного, среднего бизнеса, интернет-сервисов это важный этап профессионального юзабилити-анализа. Используя юзабилити-тестирование вместе со стандартными методами и инструментами (системами аналитики, Вебвизором, эвристическим анализом и т.д.), вы сможете выдвигать правильные гипотезы для A/B-тестов, вносить правки в сайт и добиваться устойчивого повышения конверсии.

2. Онлайн-тестирование

Развитие интернета способствовало развитию дистанционного онлайн-тестирования , которое, как правило, гораздо дешевле и быстрее. Это исследование без взаимодействия с тестировщиком в реальном времени. Если вы правильно напишете сценарий, этот метод значительно сэкономит ваши ресурсы. Конечно, можно найти удаленную фокус-группу, составить список вопросов, отослать по электронной почте и попросить людей самостоятельно протестировать сайт или продукт, проходя через сценарий и комментируя свои мысли и действия вслух. Но гораздо проще воспользоваться сервисами автоматизации. Флагманом зарубежного рынка является usertesting.com , на российском рынке мы предлагаем его аналог – . Огромные базы реальных тестировщиков позволяют мгновенно подобрать по любым параметрам фокус-группу (например, десять женщин от 30 до 35 лет, у которых есть кот) и в течение пары дней провести тестирование.

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

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

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

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

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

Что такое UX исследования?

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

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

Исследования состоят из двух частей: сбор данных и их обработка с целью улучшить юзабилити. В начале проекта дизайнерские исследования посвящены определению требований к проекту от руководителей, а также целей и нужд конечных пользователей. Сюда входит проведение интервью, опросов, изучение потенциальных или существующих пользователей, анализ имеющейся литературы и данных. Затем исследования начинают ориентироваться на юзабилити и мнения о продукте. На данном этапе проводятся A/B тестирования, интервью с пользователями о процессе взаимодействия и тестирование предположений, которые способны улучшить дизайн.

Разделить существующие методы исследования можно на два лагеря:

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

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

Общие методики

Все разнообразные типы UX исследований от личных интервью до A/B тестирования основываются на трех методиках: наблюдении, понимании и анализе.

Наблюдение

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

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

Понимание

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

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

Исследователи должны понимать ментальные модели людей, с которыми они проводят интервью, по двум причинам:

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

Анализ

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

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

Виды исследований

Все UX проекты разные, поэтому и список задач может существенно различаться. Самые популярные формы исследования: интервью, опросы и анкетирования, сортировка карточек, тестирование юзабилити, тестирование иерархии и A/B тестирование.

Интервью

Личное интервью – проверенный и доказавший свою эффективность метод коммуникации между исследователем и пользователем или руководителем. Существует три основных типа интервью, каждый из которых преследует разные цели:

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

Опросы и анкетирование

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

Тестирование удобства пользования - это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. [ISO 9126 ]

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

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

Уровни проведения

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

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

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

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

Заблуждения о тестировании удобства пользования

1. Тестирование пользовательского интерфейса = Тестирование удобства пользования

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

2. Тестирование удобства пользования можно провести без участия эксперта

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

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

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

Легко понять, что такое тестирование, при всех своих достоинствах, очень уж длительно и неприемлемо дорого.

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

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

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

Что такое юзабилити-тестирование

Юзабилити-тестированием является любой эксперимент, направленный на измерение качества интерфейса или же поиск конкретных проблем в нем.

Польза юзабилити-тестирования многогранна. Тестирование позволяет:

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

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

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

Почему по дешевке

Резко снизить трудоемкость, а значит, и себестоимость юзабилити-тестирования позволяют три подхода:

1. Некоторое упрощение понятие юзабилити.
2. Отказ от сбора количественных данных.
3. Снижение стоимости оборудования и уменьшение оплаты времени респондентов.

Третий подход заключается в использовании только мобильных лабораторий, что подробно описано в разделе . Оставшиеся два подхода описаны ниже.

Effectiveness и efficiency

В главной и наиболее употребимой трактовке (стандарт ISO 9241–11) понятие юзабилити определяется как

The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

Мой перевод этой формулировки на русский язык:

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

* Например, скорость работы или количество человеческих ошибок и длительность их исправления.

** Например, количество операций, которые нужно выполнить для достижения результата или объем информации, которую нужно переработать для принятия решения. Термин efficiency до сих пор часто переводят на русский как продуктивность ; на мой взгляд, это грубая ошибка, поскольку в оригинальном стандарте ISO 9241–11 под efficiency понимается нечто близкое к понятию КПД.

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

C показателями трудоемкости все несколько сложнее. В эту группу входят:

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

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

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

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

Нет количеству!

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

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

Качество или количество?

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

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

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

Ненадежные цифры

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

Ответ на этот вопрос прост и печален - оснований верить в результаты юзабилити-тестирования нет вовсе.

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

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

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

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

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

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

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

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

Зачем все-таки нужны цифры

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

Что именно измерять?

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

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

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

Насколько глубоко удовлетворение?

В отличие от прочих характеристик, удовлетворенность находится не в реальном мире, а в голове у пользователя. Как следствие, ее невозможно «пощупать», а значит, и объективно измерить. Но, по крайней мере, ее можно измерить опосредованно.

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

Ниже приведены некоторые методы измерения удовлетворенности.

Анкетирование

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

К сожалению, анкетирование имеет в российских условиях крупный недостаток - надежных анкет просто не существует. Несмотря на то, что в странах загнивающего Запада создано множество вполне работоспособных анкет (SUMI , QUIS ,MUMMS , IsoMetrics и др.), ни одна из них не переведена на русский язык и не протестирована заново. В результате эти анкеты, будучи, кстати сказать, весьма дорогими, ничем не надежней любых анкет, которые вы можете придумать самостоятельно.

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

Ниже приводятся две работоспособные, хотя и ненадежные, анкеты.

Анкета по словам

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

Я использую следующий набор прилагательных:

Устаревший - Эффективный - Нечеткий - Неудобный - Замусоренный - Тусклый - Яркий - Чистый - Прямой - Ясный - Непоследовательный - Неуправляемый - Привлекательный - Стандартный - Управляемый - Хороший - Интуитивный - Веселый - Любительский - Неэффективный - Опасный - Скучный - Радостный - Безопасный - Жесткий - Раздражающий - Треугольный - Неприятный - Комфортабельный - Холодный - Умный - Бесполезный - Халтурный - Теплый - Светлый - Последовательный - Загадочный - Качественный - Интересный - Ненадежный - Гибкий - Красивый - Некрасивый - Непривлекательный - Полезный - Глупый - Запутанный - Удобный - Понятный - Непредсказуемый - Четкий - Тяжелый - Современный - Легкий - Дружественный - Нестандартный - Плохой - Надежный - Сложный - Простой - Темный - Профессиональный - Медленный - Круглый - Печальный - Недружественный - Предсказуемый - Непонятный - Быстрый - Головоломный - Грустный - Приятный

Обратите внимание, что слова неслучайно даны вперемешку, именно так и нужно предъявлять их респондентам.

Формальная анкета

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

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

Вопросы анкеты:

Во время выполнения заданий я ошибался Нет/Да

Система способна делать все, что мне нужно и даже больше Нет/Да Система работает достаточно быстро Нет/Да

Мне нравится внешний вид интерфейса Нет/Да

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

Систему можно легко настроить под мои нужды Нет/Да

Начать работу было легко; я не столкнулся с существенными трудностями Нет/Да

Всякий раз, когда я ошибался, я с легкостью замечал и исправлял свою ошибку Нет/Да

Я доволен своей скоростью работы Нет/Да

Во время выполнения заданий я чувствовал себя вполне уверенно Нет/Да

В любой момент времени я понимал, что должен сделать дальше Нет/Да

Система представляется мне полезной, я бы с удовольствием использовал бы её для решения моих задач Нет/Да

Результаты нужно подсчитывать по следующему алгоритму: центральное значение дает ноль баллов, крайние значения дают либо –2 балла (левый вариант ответа), либо +2 балла (правый вариант), промежуточные значения либо –1 либо, +1 балл соответственно. Сумма баллов является сравниваемым значением.

Наблюдение за эмоциональными реакциями

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

Проблемы есть и с этим методом.

Во-первых, непонятно, как подсчитывать реакции разной силы. Сколько раз респондент должен улыбнуться, чтобы уравновесить восемь секунд отборной брани? А девять секунд брани?

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

Не связывайтесь с этим тестом, если хоть чуть-чуть не уверены в своей способности улавливать эмоции других людей (например, если вы Эм, а не Жо).

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

Что нужно для тестирования

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

• респонденты
• метод тестирования
• тестовые сценарии
• рабочее место для теста и отлаженный метод фиксации материала
• протестированный тест.

Респонденты

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

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

Общие требования к респондентам

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

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

Уровень компьютерной грамотности удобно определять по следующей шкале:

1. Высокий. Респондент имеет компьютер на работе и дома, большая часть трудовой деятельности выполняется на компьютере, респондент самостоятельно использует компьютер как средство саморазвития, активно пользуется сервисами в интернете (например, регулярно покупает товары и услуги в онлайновых магазинах).
2. Выше среднего. Респондент имеет компьютер на работе и дома, большая часть трудовой деятельности выполняется на компьютере, но респондент не использует компьютер для решения задач, выходящих за пределы его основной деятельности (работает на компьютере «от звонка до звонка» и не больше).
3. Средний. Работа с компьютером является частью обычной (трудовой или личной) деятельности в течение двух лет или больше.
4. Низкий. Либо на работе, либо дома есть компьютер, но опыт работы с компьютером не превышает двух лет и компьютер не является значимым инструментом в работе.
5. Очень низкий. Опыт использования компьютера спорадический, по длительности не превышает трех лет. Компьютер не используется ни на работе, ни дома.

На третьем месте стоит возраст. Оптимальная пропорция: три четверти респондентов имеет возраст целевой аудитории системы, оставшаяся четверть старше (на ней можно определить большее количество проблем).

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

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

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

Сколько нужно респондентов

В 1992 году Роберт Вирзи (Robert Virzi) в статье Refining the test phase of usability evaluation: how many subjects is enough? предположил, что для теста достаточно пяти респондентов. Через год эстафету приняли Якоб Нильсен и Томас Ландауэр (Jakob Nielsen и Thomas K. Landauer) со статьей A mathematical model of the finding of usability problems, в которой утверждали, что пяти респондентов достаточно для того, чтобы выловить 70% проблем и еще три респондента нужны для того, чтобы довести результативность до 85%.

Юзабилити-сообщество полюбило эти цифры всей душой. С тех пор фраза «5–8 респондентов» стала чуть ли не мантрой. Увы, эта мантра ложна.

Во-первых, все три автора писали только о тестировании маленьких систем. Что делать, если система слишком велика, чтобы можно было уместить тест на каждом респонденте в полтора часа (это максимум, который может выдержать человек, как респондент, так и экспериментатор; гораздо лучше тесты по 40 минут). В этом случае придется выполнять несколько разных тестов на разных респондентах; без этого охватить весь интерфейс системы окажется попросту невозможно. Сколько респондентов при этом понадобится - зависит от системы, четких градаций тут быть не может. Так, для тестирования крупного корпоративного сайта, по-хорошему, нужно человек двадцать несколькими сериями по 5 человек.

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

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

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

Организационные вопросы

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

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

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

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

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

Договариваясь с респондентом о встрече, проявляйте максимальную гибкость и податливость. Респондент, даже если его время оплачивается, делает вам одолжение, соглашаясь участвовать в тестировании.

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

Методы тестирования

Основных методов юзабилити-тестирования всего три: пассивное наблюдение за выполнением тестовых заданий, поток сознания и активное вмешательство; первый предназначен для сбора количественных данных, последний - качественных:

• Пассивное наблюдение за выполнением тестовых заданий. Сущность метода очень проста: респондент выполняет тестовые задания, его действия анализируются (во время теста или после, по протоколам), что позволяет как найти проблематичные фрагменты, так и замерить эргономические характеристики интерфейса.
• Поток сознания (think aloud). Соответствует проверке посредством пассивного наблюдения, но респондента при этом просят также устно комментировать свои действия. Затем комментарии анализируются. Метод довольно нестабильный, но порой дающий интересные результаты (очень зависит от разговорчивости респондента). Крупный минус потока сознания - измерения эргономических характеристик интерфейса весьма сомнительны.
• Активное вмешательство. В этом методе юзабилити-специалист не ждет милостей от природы в лице респондента, а старается взять их сам. После каждого действия респондента экспериментатор выспрашивает его, почему респондент действует именно так; на каждом экране экспериментатор спрашивает, как именно респондент понимает назначение и функции этого экрана. Этот метод ближе к фокусированному интервью, чем к собственно тестированию - например, метод можно использовать даже без тестовых заданий, лишь бы был интерфейс для обсуждения. Понятно, что при активном вмешательстве никакие измерения попросту невозможны, но зато объем получаемых качественных данных наиболее велик.

Тестовые сценарии

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

Сценарии состоят из пользовательской задачи и сопутствующих ей:

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

Разберем их подробно.

Пользовательская задача

Первым шагом определения сценариев является определение значимых пользовательских задач. Эти задачи - исходный материал для составления сценариев.

Что такое пользовательская задача? Это задача, которую ставит перед пользователями их деятельность, и которая имеет самостоятельную ценность для пользователей. Пользовательская задача выполняется как одна или несколько операций (пользовательская операция не имеет самостоятельной ценности). Например, для программы-почтового клиента задачами являются:

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

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

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

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

Значимые эргономические метрики задачи

Для каждой задачи нужно выбрать значимые для нее характеристики интерфейса. Конечно, в нашем распоряжении есть метрики из раздела «Что именно измерять». Однако эти метрики неудобны: их трудно измерять и трудно понять (правда, их легче сравнивать). С практической точки зрения гораздо удобнее более приземленные характеристики.

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

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

Вот примеры таких метрик:

• Успешность - респонденты правильно выполняют 90% заданий.
• Эффективность - скорость работы пользователя: регистрация на сайте выполняется меньше чем за 7 минут.
• Эффективность - ошибки: при вводе 10 форм количество ошибок ввода не превышает двух.
• Эффективность - обучаемость навыкам работы с системой: при выполнении задания 9, отличающегося от задания 2 только вводимыми данными, респонденты не совершают ни одной ошибки (не считая опечаток).
• Удовлетворенность - по результатам анкетирования число баллов выросло на 20% по сравнению с прежними результатами.

Тестовые задания

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

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

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

Помимо этих общих требований нужно учитывать еще и следующее:

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

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

Признаки успешности выполнения задачи

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

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

Рабочее место и способы фиксации данных

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

Итак, что нужно иметь для полноценного тестирования:

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

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

3. Микрофон. В принципе, подойдет любой. Лично я пользуюсь обычным микрофоном Genius стоимостью в семьдесят рублей. Если в веб-камеру встроен микрофон, вполне подойдет и он. С другой стороны, более качественный микрофон дает лучшее качество записи, так что будет меньше шипения (но оно ничему не мешает).

4. Программа записи содержимого экрана. Фактическим стандартом является TechSmith Camtasia, если же позволяют средства, инвестируйте в TechSmith Moraе, специально предназначенную для юзабилити-тестирования (она записывает не только содержимое экрана, но и регистрирует действия пользователя, что позволяет сильно ускорить последующий анализ - с другой стороны, Moraе в четыре раза дороже, чем Camtasia, которая и так штука недешевая).

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

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

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

Уважаемый [Имя респондента]!

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

При выполнении заданий Вы должны действовать так, как считаете нужным. Например, если Вы решите воспользоваться Справкой, вы можете это сделать, не спрашивая разрешения экспериментатора.

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

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

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

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

Если Вы не понимаете какое-либо задание, не стесняйтесь, переспросите проводящего тестирование специалиста.

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

7. Если вы собираетесь анкетировать пользователей, понадобятся распечатанные анкеты.

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

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

Запись мимики респондентов

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

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

Не располагайте микрофон возле распечаток тестовых заданий. Оглохнете при просмотре видео.

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

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

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

1. Выключите ускорение графики в Windows (в Панели управления выберите Экран , на вкладке Параметры нажмите кнопку Дополнительно , в открывшемся окне на вкладке Диагностика переведите ползунок Аппаратное ускорение в левую часть). После теста ускорение можно включить снова.
2. Запустите любую программу, способную выводить приходящее с камеры видео. Такие программы придаются к веб-камерам, кроме того, подходят программы для видеочата.
3. Установите в правый нижний край экрана окно с приходящей с камеры картинкой (там оно менее всего отвлекает респондента), а окно самой тестируемой системы расположите так, чтобы оно не заслоняло картинки. Окно с видео стоит заклеить бумажкой (благодарю Дмитрия Сатина за идею).
4. Попросите респондента не изменять размер окна тестируемой системы.
5. Включите запись всего содержимого экрана.

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

Вид экрана при записи мимики таким способом.

Дополнение : В третьей версии TechSmith Camtasia Studio появился режим «картинка-в-картинке» (в угол видеозаписи с содержимым экрана вставляется поток от видеокамеры), так что теперь все стало гораздо проще.

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

Протестированный тест

Наконец, нам нужно проверить сам тест. Нужно убедиться, что:

1. аппаратура работоспособна
2. вы умеете с ней обращаться как младой полубог
3. все настройки по умолчанию правильны
4. у вас достаточно чистых кассет или места на диске
5. все необходимые бумаги распечатаны и проверены на актуальность и ошибки
6. тестовые задания содержат все необходимые сведения и не требуют дополнительных пояснений
7. в тестовых заданиях нет скрытых подсказок
8. вы умеете быстро приводить тестируемую систему в изначальное состояние, чтобы следующие респонденты не видели изменений, вносимых предыдущими участниками
9. ваше представление о том, что является правильным выполнением заданий, истинно
10. тест на одном респонденте может быть проведен за разумное время (не более полутора часов).

Как видим, пунктов, в которых можно допустить ляпы, настолько много, что сама по себе их проверка станет источником ошибок (сложные задачи трудно выполнить вообще без ошибок). Соответственно, нужен надежный метод проверки. Таким методом является тестирование самого теста, т.е. прогон теста на ком-то, кого не жалко и кого нетрудно отловить (например, на сослуживце). Если тестовый прогон показал хотя бы одну ошибку в подготовке теста, иcправьте ее и повторите прогон снова.

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

Проведение тестирования

Итак, тест подготовлен и можно приступать. Процедура проста. Включив запись и усадив респондента за компьютер:

1. введите респондента в задачу
2. выясните у него его ожидания от системы
3. протестируйте интерфейс
4. выясните, насколько оправдались ожидания респондента
5. завершите тест.

Ниже эти шаги описаны подробно.

Введение в задачу

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

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

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

Выявление ожиданий от системы

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

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

Процедура выявления ожиданий состоит из двух шагов:

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

Тестирование

При тестировании нужно следовать следующим шести «никогда»:

• Никогда не извиняйтесь за несовершенство тестируемой системы.
• Никогда не говорите «Мы потом это исправим».
• Никого не обвиняйте в том, что интерфейс плох («Разработчики, конечно, придурки, и создали нечто несуразное, но мы с вами это щас исправим»).
• Никогда не называйте процесс тестирования «пользовательским тестированием» - респондент решит, что тестируют его, и будет бояться. Идеально, если вы всегда будете называть процедуру «юзабилити-тестирование интерфейса» или просто «тестирование интерфейса».
• Никогда не прерывайте респондента. Даже если он говорит нечто неактуальное, дайте ему полностью выговориться и только тогда задавайте свои вопросы.
• Никогда не формируйте поведение респондента. Некоторые люди подстраиваются под ожидания экспериментатора, например, почувствовав, что вам хочется найти в интерфейсе побольше ошибок, они будут постоянно ошибаться сами, даже если в интерфейсе нет предпосылок для этого. Чтобы избежать такого результата, все ваши слова должны быть подчеркнуто нейтральными. Достигнуть нейтральности помогают два простых метода. Во-первых, не стоит задавать вопросы с единственным вариантом ответа. Вместо того, чтобы спрашивать респондента, насколько простой показалась ему система (это явно наводящий вопрос, поскольку его можно задать иначе с другим отношением к теме - «насколько сложной показалась вам система?»), лучше спросить, простой или сложный у системы интерфейс. Во-вторых, часто респонденты сами задают вам вопросы, стараясь избежать необходимости принимать решение самому. Ответить на такие вопросы легко, вот только ответы, из-за их спонтанности, будут наводящими. В таких случаях лучший ответ - встречный вопрос. Я справляюсь? - А как вы сами думаете? Я выполнил задание правильно? - А как вы сами считаете? И так далее, пока респондент не угомонится. Невежливо, но действенно.

Кроме того, есть несколько не столь категоричных правил:

• Если во время теста вы следите за каким-либо свойством интерфейса, например, считаете ошибки респондента, не следует следить больше чем за одним показателем. К примеру, если вы считаете ошибки, время выполнения операций считать не стоит - вероятность вашей собственной ошибки слишком уж возрастает. На мой взгляд, во время теста можно только записывать свои гипотезы о потенциальных улучшениях интерфейса - т.е. то, что вы видите сразу же. Высчитывать показатели интерфейса лучше по видеозаписям.
• Даже при активном вмешательстве старайтесь не задавать респонденту вопросов, не относящихся напрямую к его текущей операции. Лучше задать их после теста.
• По возможности сидите справа сзади от респондента - так, чтобы он мог увидеть ваше лицо, слегка повернув голову. Ваше присутствие для респондента обременительно, но в таком положении он хотя бы будет менее напряжен.
• Во время теста вы часто не можете увидеть проблемы с интерфейсом в целом. Например, вы заметили ошибку пользователя. Но чем она объясняется? Аномалия ли это, вызванная тем, что пользователь менее подготовлен, чем остальные? Уверены ли вы в том, что эту ошибку повторяют все? Из-за этого фиксировать нужно максимум наблюдений. Некоторые вы отбросите впоследствии, но это лучше, чем упустить проблему.

• Скорость работы. Между заданиями переводите секундомер на новый круг. Если респондент по какой-либо причине отвлекается, ставьте секундомер на паузу.
• Ошибки. На листе бумаги ставьте черточку при каждой человеческой ошибке. Удобно ставить мелкие черточки при мелких ошибках и длинные - при ошибках крупных. После теста достаточно посчитать количество черточек. Если вы раздельно считаете ошибки разных типов (например, просто ошибки и отдельно неправильно выбранные элементы меню) лучше пользоваться разными кодами, например, теми же черточками при простых ошибках и буквами М при ошибках, связанных с меню.
• Проблемы, которые вы видите сразу же. Кратко записывайте на бумажке сущность проблемы и текущее время (время первым!). Если вы будете точно знать, когда произошла проблема, вам будет легче найти соответствующий фрагмент видеозаписи.
• Эмоциональные реакции респондента. Ставьте знак плюса при положительных реакциях и знак минуса - при отрицательных. Реакции, происходящие в момент завершения тестовых заданий, не считаются.

Завершение теста

Закончив тест:

• Задайте респонденту накопившиеся вопросы.
• Дайте респонденту заполнить анкеты, если вы проводите анкетирование.
• Спросите у респондента, понравился ли ему интерфейс; независимо от ответа попросите уточнить, что именно понравилось и что не понравилось.
• Расплатитесь с респондентом.
• Поблагодарите его за участие в тесте. Заверьте респондента, что он справился прекрасно и что благодаря ему вы смогли выявить много интерфейсных проблем (сделайте это даже если респондент оказался замкнутым, неприятным в общении типом, тест на котором не выявил ничего нового).
• Если респондент особо хорош, спросите его, можно ли обращаться к нему в будущем для новых задач тестирования. Респондент с опытом тестирования всегда лучше такого же, но без опыта.

Тестирование на прототипах

Особо следует остановиться на тестировании на прототипах. При тестировании на прототипах у вас есть две возможности:

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

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

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

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

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

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

Анализ результатов

Наконец, пришло время для анализа результатов тестирования. Здесь важны три вещи:

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

Особняком стоит вопрос, когда начинать оптимизировать интерфейс.

Когда начинать анализ

Анализировать результаты можно как во время, так и после теста. Анализ во время тестирования имеет достоинства и недостатки. К достоинствам относится то, что он:

• Позволяет сэкономить время на этапе анализа, т.к. часть анализа производится во время более раннего этапа.
• Дает наиболее непосредственное впечатление от теста (гештальт), что позволяет увидеть проблемы, не замечаемые никаким другим способом.

Есть и недостатки:

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

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

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

Анализ действий респондентов

Почти любое юзабилити-тестирование направлено на поиск и выявление проблем. Но как увидеть проблему в действиях респондентов?

Ошибки

Не любая ошибка респондента объясняется проблемами интерфейса, например, респондент мог проявить элементарную невнимательность. Тем не менее, любая ошибка требует рассмотрения:

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

Замедления выполнения задания

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

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