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

22 Декабрь

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

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

Действительно ли нужен данный вид тестирования?

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

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

Что считают основой при составлении тестирования?

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

Ключевые сценарии.

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

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

Вопросы.

В команде могут возникнуть вопросы, которые требуют исследования. К таким вопросам можно отнести: “Стоит ли вводить баннер, в котором будет реклама дополнительных продуктов?”, “Понятны ли названия наших разделов?”.

Гипотезы.

Обычно под ними понимают преобразованные и уже известные вопросы и проблемы команды.  Самым лучшим кейсом можно считать – когда заказчик может сам предоставить гипотезы. К примеру, “Чаще всего наши клиенты выбирают оплату с телефона, с включенной комиссией, может быть, они просто не знают о лучших вариантах оплаты?” В случае, если заказчик не может самостоятельно предоставить гипотезы, но он обладает желанием проверить свой проект на понятность для пользователя – то вы должны сами сформулировать их.

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

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

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

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

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

Сбор данных

модерирование UX-тестирования

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

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

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

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

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

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

Индикаторы производительности: Измерение опыта пользователя

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

Многообразие показателей в оценке юзабилити

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

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

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

  1. Задача выполнена легко — 100 % успеха;
  2. Были трудности, но задача выполнена самостоятельно — 50 % успеха;
  3. Задача не выполнена — 0%.

Например, если из 14 человек 6 легко прошли тестирование, 8 столкнулись с трудностями, а 4 не смогли выполнить задачу, то средний уровень успешности составит 58%. Эта ясная метрика эффективна, особенно при явных целях задач.

График успешности по заданиям выявляет наиболее проблемные моменты интерфейса.

Время исполнения задач: Этот показатель становится информативным при сравнении. Как оценить, насколько хорошо, если пользователь выполнил задание за 1 минуту?  Без сравнения с предыдущей версией дизайна или с метриками конкурента – эта метрика бессмысленна.

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

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

Как метрики влияют на оценку удобства

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

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

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

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

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

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

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

Готовимся к тестированию: Ключи успешного эксперимента

модерирование ux тестирования веб-приложений

Помимо выбора метода, определения метрик и разработки протокола тестирования, перед вами стоит ряд важных аспектов:

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

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

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

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

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

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

Также определите формат отчета: подробный отчет с данными или общий файл с наблюдениями.

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


3994
Контакты
Россия
129085, г.Москва, ул. Годовикова д.
9, стр. 2, подъезд 2.1, офис 2.22