Юзабилити-тестирование: пошаговая инструкция на примере Yelp. Зачем все-таки нужны цифры

Интервью / фокус-группа

Массовый опрос

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

Полевое исследование

Карточная сортировка

Мультиканальное исследование

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

Артефакты

Бизнес-требования

Портреты пользователей

Требования пользователей

Спланировать проект

Методы и артефакты

• Интервью / фокус-группа
• Массовый опрос
• Полевое исследование
• Карточная сортировка
• Мультиканальное исследование

Интервью / фокус-группа

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

Массовый опрос

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

Полевое исследование

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

Карточная сортировка

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

Мультиканальное исследование

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

Артефакты

• Бизнес требования
• Портреты пользователей
• Портреты деятельности
  пользователей
• Требования пользователей

Бизнес требования

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

Портреты пользователей

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

Портреты деятельности пользователей

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

Требования пользователей

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

60 000 юзабилити-часов

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

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

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

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

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

Мы используем множество различных методов в зависимости от бизнес-задач клиентов. Одни клиенты приходят за «инсайтами», им требуется приток новых идей о том, где «хромает» юзабилити. Другие приходят со своими идеями и хотят их количественно проверить и приоритизировать согласно потребностям пользователей. Третьи нуждаются в построении эффективной каталожной системы. Методология Human Centered Design предлагает достаточный набор инструментов, которые можно комбинировать и найти ответы на важные для бизнеса вопросы о пользовательских качествах продукта.

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

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

Каких результатов можно добиться при помощи юзабилити-тестирования сайта?

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

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

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

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

Качественное тестирование.

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

Количественное тестирование.

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

Сравнительное тестирование.

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

Кросс-культурное тестирование.

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

Пользовательское тестирование

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

Айтрекинг-тестирование

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

Тестирование методом персонажей

Цель - понять поведение на сайте типичных представителей различных групп ЦА и на основе полученных знаний об их предпочтениях удовлетворить наиболее широкую группу пользователей.

Экспертный анализ

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

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

Цель - предложить пользователям несколько вариантов дизайна и сравнить реакцию. Выделяются последовательные и параллельные A/B-тесты. При последовательном тестировании usability правки сразу вносятся на сайт и замеряются периоды до и после изменений. При параллельном делается несколько версий, которые сравниваются с основной.

Все перечисленные методики тестирования так или иначе влияют на повышение юзабилити, но компания Demis Group, основываясь на своем большом опыте, использует два направления:

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

Подготовка к юзабилити-тестированию и получение отчета

Подготовка состоит из 4 основных этапов:

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

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

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

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

Как подобрать респондентов для тестирования юзабилити?

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

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

Как создать сценарий для респондентов?

Чтобы создать сценарий пользователя, важно понять 3 вещи:

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

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

С какими проблемами уже сталкивались пользователи. Возможно, об этом писали в службу поддержки.

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

Вот в качестве примера два варианта задания:

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

Забронируйте номер в отеле Италии.

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

Примеры наших кейсов по юзабилити-тестированию

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

Процедура состоит из двух этапов.

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

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

Анализ результатов тестирования юзабилити

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

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

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

Примерное описание удобного ресурса

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

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

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

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

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

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

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

Информацию на сайте легко найти, и она соответствует запросам аудитории.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Важно: статья появилась еще 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. После теста у респондента нужно выспросить, насколько показанный интерфейс соответствует его ожиданиям. Здесь респонденту уже вполне можно верить: во-первых, он подготовлен своими предыдущими ответами, а во-вторых, показанный ему интерфейс может побудить его сформулировать требования, которых он раньше не осознавал.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ошибки

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

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

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

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

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

Подготовка, интервью и сбор данных

В закладки

Руководитель направления UX-исследований Mail.Ru Group Наталия Спрогис в блоге компании на «Хабрахабре» рассказала о подготовке и проведении юзабилити-тестирований: что включить в сценарий теста, как выбрать метод сбора данных, составить задания и собрать впечатления респондентов.

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

Точно ли нужно тестирование

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

Например, мы никогда не беремся в качественных исследованиях проверять «привлекательность» какой-то функции или варианта дизайна. Мы можем собрать с пользователей отзывы, но слишком велик риск, что на их ответы повлияет социальная желательность. Люди всегда склонны сказать, что стали бы пользоваться даже тем, чем пользоваться не будут. Да и маленький размер выборки не позволяет доверять таким ответам. Например, у нас был неудачный опыт тестирования игровых лендингов: лендинг, который выбирали как наиболее привлекательный на тесте, при A/B-тестировании отработал гораздо хуже.

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

Основа для составления сценария юзабилити-теста

Планирование тестирования начинается не с составления текста заданий, а с детальной проработки целей и вопросов исследования совместно с проектной командой. Вот основа для составления плана:

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

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

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

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

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

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

Метод сбора данных

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

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

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

Think Aloud (мысли вслух). Долгое время этот метод использовался в юзабилити-тестированиях чаще всего. Якоб Нильсен в свое время называл его главным инструментом оценки юзабилити. Суть в том, что вы просите респондента озвучивать все мысли, возникающие у него при работе с интерфейсом, и комментировать все свои действия. Это выглядит примерно так: «Сейчас я собираюсь добавить этот товар в корзину. А где же кнопка? А, вот она. Ой, я забыл посмотреть, какой там был цвет».

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

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

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

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

Retrospective think aloud, RTA (ретроспектива). Это комбинация первых двух методов. Пользователь сначала выполняет все задания без вмешательства, а потом перед ним проигрывается видеозапись его работы, и он комментирует свое поведение и отвечает на вопросы модератора. Главный недостаток метода - сильно увеличивается время тестирования. Однако бывают случаи, когда он оптимален.

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

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

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

Метрики

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

Какие бывают метрики

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

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

• справился с заданием практически без проблем - 100%;
• столкнулся с проблемами, но выполнил задание самостоятельно - 50%;
• не справился с заданием - 0%.

Если из 12 респондентов 4 справились с заданием легко, 6 - с проблемами, а 2 потерпели фиаско, то средняя успешность по этому заданию будет 58%.

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

Чтобы избежать слишком большой субъективности, продумайте шкалы оценок заранее, а не решайте для каждого респондента после теста. Также стоит подумать, что делать с ошибками. Например, вы дали задание купить билеты в кино на проекте «Кино Mail.Ru». Один из респондентов случайно купил билет не на завтра, а на сегодня, и не заметил этого. Он уверен, что справился с заданием и имеет билет на руках. Но его ошибка настолько критична, что он не попадет в кино, поэтому я бы поставила «0%», несмотря на то что билет куплен.

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

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

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

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

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

Субъективная удовлетворенность. Это субъективная оценка пользователем удобства или комфорта работы с системой. Выявляется она при помощи опросников, которые респонденты заполняют в процессе или после тестирования. Есть стандартные опросники. Например, System Usability Scale, Post-Study Usability Questionnaire или Game Experience Questionnaire для игр. Или вы можете составить собственный опросник.

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

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

Трактовка метрик

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

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

Когда нужны метрики

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

• Доказать. Часто есть необходимость доказать, что в продукт нужно внести изменения, - особенно в крупных компаниях. Для лиц, принимающих решения, цифры наглядны, понятны и привычны. Когда вы показываете, что 10 из 12 респондентов не смогли оплатить товар или что регистрация в системе занимает в среднем в два раза больше времени, чем у конкурентов, - это придает результатам исследования больший вес.
• Сравнить. Если вы сравниваете свой продукт с другими на рынке, вам также не обойтись без метрик. Иначе вы увидите достоинства и недостатки разных проектов, но не сможете оценить, какое место ваш продукт занимает среди них.
• Увидеть изменения. Метрики хороши для регулярных тестов одного и того же продукта после внесения изменений. Они позволяют увидеть прогресс после редизайна, обратить внимание на те места, которые остались без улучшений. Использовать эти показатели вы можете опять же как доказательную базу, которая покажет руководству вес вложений в редизайн. Или просто для понимания того, что вы достигли результатов и движетесь в нужном направлении.
• Иллюстрировать, сделать акцент. Цифры хорошо помогают иллюстрировать важные проблемы. Иногда мы считаем их для наиболее ярких и важных моментов теста, даже если не используем метрики во всех заданиях.

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

Способ фиксации данных

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

Чтобы оптимизировать время на анализ, хорошо заранее заготовить шаблон для ввода заметок в процессе теста. Мы пробовали делать это в специализированном программном обеспечении (например, Noldus Observer или Morae Manager), но на практике наиболее гибкими и универсальными оказались таблицы. Заранее разметьте в таблице вопросы, которые точно планируете задавать, места под ввод проблем, обнаруженных в заданиях, а также гипотезы (на каждом респонденте вы будете помечать, подтвердились она или нет). Наши таблички выглядят подобным образом:

Чем еще вы можете воспользоваться:

• . Кастомизируемый шаблон Excel для ввода наблюдений по каждому респонденту. Встроен таймер, который измеряет время выполнения заданий, автоматически генерируются графики времени и успешности.
• Rainbow Spreadsheet от Томера Шерона из Google. Наглядная таблица для совместной работы исследователя и команды. Ссылка ведет на статью с описанием метода, там же есть ссылка на Google-таблицу с шаблоном.

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

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

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

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

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

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

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

Можно использовать средства продукта для постановки заданий. Например, при тестировании ICQ задания респонденты получали через окно чата с модератором, а при тестировании «Почты Mail.Ru» они приходили в письмах. Такой способ постановки заданий был максимально естественным для этих проектов, а еще мы многократно обкатывали базовые сценарии переписки.

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

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

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

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

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

Протокол любого юзабилити-тестирования состоит из следующих частей:

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

Инструктаж или брифинг

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

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

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

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

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

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

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

Вводное интервью

Оно решает следующие задачи:

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

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

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

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

Работа с продуктом, составление заданий

Какие бывают задания

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

Сфокусированные задания. Кажется очевидным сделать примерно такое задание: «Выберите посудомоечную машину шириной 45 сантиметров с функцией "луч на полу" стоимостью не более 30 тысяч рублей». Это мотивирует респондента пользоваться фильтрами и сравнивать товары между собой. Вы сможете проверить фильтр по цене на всех респондентах и посмотреть на ключевой сценарий подбора товара. Подобные задания вполне имеют право на жизнь и хороши для проверки конкретных гипотез (как с фильтром по цене).

Однако, если весь тест будет состоять из них, то вы рискуете следующим:

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

Задания с контекстом. Один из способов лучше вовлечь пользователей - добавить в сухое задание реальную историю и контекст. Например, вместо «Найдите на сайте рецепт пирога со сливами» предложите следующее: «Через час к вам придут гости. Найдите, что можно испечь за это время. У вас в холодильнике есть все для бисквита, а также немножко слив. Но, к сожалению, нет сливочного масла».

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

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

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

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

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

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

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

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

Важно, чтобы модератор при этом выходил из комнаты. В противном случае у пользователя появляется соблазн сразу же что-то спросить, уточнить: «А надо ли регистрироваться? А как вот это сделать?» и так далее.

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

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

Составляем хорошие задания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сбор итоговых впечатлений

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

Интервью с модератором

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

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

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

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

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

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

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

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

Мера удовлетворенности

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

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

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

• After Scenario Questionnaire (ASQ) . Три вопроса о сложности, продуктивности и подсказках в системе.
• Single Ease Question (SEQ) . Один вопрос о сложности сценария.

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

• System Usability Scale и Post-Study System Usability Questionnaire . Два классических и популярных опросника, созданных более 20 лет назад. Оба состоят из утверждений. Респонденты должны указать степень согласия с ними. Все эти утверждения с разных сторон характеризуют юзабилити продукта. Например: «Я легко мог найти нужную информацию», «Разные возможности системы легко доступны» и так далее.
• . Опросник, который часто помогает нам на тестах. Пользователю предоставляется набор прилагательных, из которых он выбирает те, что могут характеризовать продукт. В итоге вы получаете облако слов - характеристик вашего проекта. Часто эта методика приносит очень интересные результаты.
• Game Experience Questionnaire . К играм нельзя применять классические юзабилити-опросники: вовлеченность в игровой процесс гораздо важнее, чем понятность интерфейсов. Поэтому для игр нужно всегда составлять особые опросники или пользоваться Game Experience Questionnaire. Опросник содержит несколько модулей: базовый модуль, внутриигровой блок, постопросник и опросник социальных возможностей игры.
Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.