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

Привет! Это Наталия Спрогис из UX-лаборатории Mail.Ru Group. Сегодня я расскажу о планировании и подготовке такого вида исследований, как юзабилити-тестирование. Статья рассчитана в первую очередь на неопытных исследователей и тех, кто собирается впервые проводить юзабилити-тестирование.

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

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

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

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

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

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

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

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

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

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

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

• Наблюдение. Во время выполнения заданий респондент оставлен наедине с продуктом и ведет себя так, как считает нужным. Комментарии респондента собираются посредством опросников и общения с модератором после теста. Это наиболее «чистый» метод, обеспечивающий более естественное поведение респондента и возможность корректно измерить ряд метрик (например, время выполнения задания). Однако за кадром остается много полезных качественных данных. Видя то или иное поведение респондента, вы не можете понять, почему он так действует. Конечно, можно спросить об этом в конце теста, но, скорее всего, респондент будет хорошо помнить только последнее задание. Кроме того, за время выполнения заданий его мнение о системе может меняться, и вы получите только итоговую картину, а не первые впечатления.
• Think Aloud (Мысли вслух). Долгое время этот метод использовался в юзабилити-тестированиях чаще всего. Якоб Нильсен в свое время называл его главным инструментом оценки юзабилити. Суть его в том, что вы просите респондента озвучивать все мысли, которые возникают у него при работе с интерфейсом и комментировать все свои действия. Это выглядит примерно так: «Сейчас я собираюсь добавить этот товар в корзину. А где же кнопка? А, вот она. Ой, я забыл посмотреть, какой там был цвет». Метод помогает вам понимать, почему пользователь ведет себя тем или иным образом, и какие эмоции вызывает у него текущее взаимодействие. Он дешев и прост, с ним справится даже неопытный исследователь. Однако у него есть свои недостатки. Во-первых, для людей не слишком естественно все время «думать вслух». Они будут часто замолкать, и вам придется им постоянно напоминать о том, что надо продолжать говорить. Во-вторых, задания при таком методе выполняются несколько дольше, чем в реальной жизни. Кроме того, часть респондентов начинает более вдумчиво пользоваться продуктом. Проговаривая причины своих действий, они стараются действовать более рационально, да и просто не хотят выглядеть идиотами. И вы можете не поймать какие-то интуитивные моменты поведения.
• Активное вмешательство модератора. Данный метод идеален для тестирования концепций и прототипов. В этом случае модератор активно взаимодействует с пользователем во время выполнения заданий, выясняя в нужные моменты причины его поведения и задавая уточняющие вопросы. В некоторых случаях модератор даже может выдавать незапланированные задания, вытекающие из диалога. Данный метод позволяет собрать максимальное количество качественных данных. Однако его можно применять, только если вы доверяете профессионализму своего модератора. Некорректно сформулированные или не вовремя заданные вопросы могут очень сильно повлиять на поведение и впечатления респондента, и даже сделать результаты теста невалидными. Также при использовании этого метода невозможен замер практически никаких метрик.
• Retrospective think aloud (Ретроспектива). Это комбинация первых двух методов. Пользователь сначала выполняет все задания без вмешательства, а потом перед ним проигрывается видеозапись его работы, и он комментирует свое поведение и отвечает на вопросы модератора. Главный недостаток метода — сильное увеличение времени тестирования. Однако бывают случаи, когда он оптимален. Например, один раз перед нами встала задача протестировать несколько видов мобов (игровых монстров) в одной RPG-игре. Естественно, мы не могли ни отвлекать респондентов вопросами, ни заставлять их комментировать свои действия во время боя. Это бы сделало невозможным игру, где нужна концентрация для победы. С другой стороны, вспомнить после серии схваток, заметил ли он загоревшуюся красным секиру у первой крысы, пользователь вряд ли смог бы. Поэтому в этом тесте мы воспользовались RTA. С каждым пользователем мы пересматривали их бои и обсуждали, какие эффекты монстров они заметили, и как их поняли.

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

Метрики

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

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

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

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

  То есть, если из 12 респондентов 4 справились с заданием легко, 6 с проблемами, а 2 потерпели фиаско, то средняя успешность по этому заданию будет 58%. Иногда вы будете сталкиваться с ситуацией, когда в среднюю группу попадают очень разные по степени «проблемности» респонденты. Например, один респондент мог мучиться над каждым полем формы, а второй лишь немного ошибиться в самом конце. Вы можете давать оценку на собственное усмотрение, в зависимости от того, что произошло на тесте. Например, 25%, если респондент только начал выполнять задание или 80%, если допустил незначительную ошибку. Однако, чтобы избежать слишком большой субъективности, продумайте шкалы оценок заранее, а не решайте для каждого респондента после теста. Также вам стоит подумать, что делать с ошибками. Например, вы дали задание, купить билеты в кино на проекте Кино Mail.Ru. Один из респондентов случайно купил билет не на завтра, а на сегодня, и не заметил этого. Он уверен, что справился с заданием и действительно имеет билет на руках. Однако его ошибка настолько критична, что приведет к тому, что он не попадет в кино, поэтому я бы поставила «0%», несмотря на то, что билет куплен. Процент успешности — это очень простая и наглядная метрика. И я рекомендую ее использовать, если у ваших заданий есть четкие цели. Взгляд на график успешности по заданиям позволяет быстро понять, где самые проблемные места интерфейса.

• Время выполнения заданий. Эта метрика показательна только в сравнении. Как вы поймете, плохо или хорошо то, что пользователь выполняет задачу за 30 секунд? А вот то, что время сократилось по сравнению с предыдущей версией дизайна, уже хорошо. Или то, что регистрация на нашем проекте занимает меньше времени, чем у конкурентов. Есть интерфейсы, где сокращение времени на выполнение задач критично. Например, рабочий интерфейс сотрудника колл-центра. Однако не для всех задач эта метрика в принципе применима. Возьмем, к примеру, задачу подбора товара в интернет-магазине. Пользователи должны быстро находить фильтры и другие элементы интерфейса, связанные с поиском товаров, но сам процесс выбора будет занимать у них разное время. И это совершенно нормально. Женщины при выборе туфель бывают готовы отсмотреть 20 страниц выдачи. И это необязательно значит, что на первых страницах не было подходящих товаров или что они не видят фильтры. Часто им просто хочется увидеть все варианты.
• Частотность проблем. Любой отчет о юзабилити-тестировании содержит список проблем, с которыми столкнулись респонденты. То, сколько респондентов столкнулось с проблемой, является показателем частотности данной проблемы в рамках теста. Данную метрику можно применять только в том случае, если ваши пользователи выполняли абсолютно одинаковые задания. Если же в тесте были вариации или задания были не четко сформулированы, а составлены на основании интервью, то посчитать частотность будет сложно. Нужно будет считать не только столкнувшихся, но и оценивать то, сколько респондентов могло бы столкнуться с проблемой (выполняли схожую задачу, заходили в тот же раздел). Тем не менее, это достаточно полезная характеристика для команды, позволяющая понять, какие проблемы стоит исправлять в первую очередь.
• Субъективная удовлетворенность. Это субъективная оценка пользователем удобства/комфорта работы с системой. Выявляется она при помощи различных опросников, которые респонденты заполняют в процессе или после тестирования. Есть стандартные опросники. Например, System Usability Scale (SUS), Post-Study Usability Questionnaire (PSSUQ) или Game Experience Questionnaire (GEQ) для игр. Или вы можете составить собственный опросник. Подробнее о способах оценки удовлетворенности во второй части статьи.

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

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

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

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

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

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

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

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

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

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

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

Казалось бы, чем плох блокнотик и ручка или просто открытый документ Word? В современном Agile мире разработки UX-исследователи должны стараться максимально быстро выдавать команде результаты своих наблюдений. Чтобы оптимизировать время на анализ, хорошо заранее заготовить шаблон для ввода ваших заметок в процессе теста. Мы пробовали делать это в специализированном ПО (например, Noldus Observer или Morae Manager), но на практике наиболее гибкими и универсальными оказались таблицы. Заранее разметьте в таблице вопросы, которые точно планируете задавать, места под ввод проблем, обнаруженных в различных заданиях, а также гипотезы (вы будете помечать, подтвердилась она или нет на каждом респонденте). Наши таблички выглядят подобным образом:

Вы также можете воспользоваться:

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

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

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

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

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

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

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

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

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

Заключение

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

Автор: Mail.Ru Group

Источник