Сегодня мы поговорим о стратегии и организации процесса исследований, специфически о таком методе, как тестирование на юзабилити. Данный материал адресован в первую очередь тем, кто только начинает свой путь в этой области исследований.
Чаще всего под планом тестирования понимают, с одной стороны – список задач, набор вопросов и анкет, которые выдаются каждому участнику, а с другой стороны – методологический фундамент исследования: гипотезе или метрики, которые требуется проверить и зафиксировать, а также инструменты, которые будут применяться.
Действительно ли нужен данный вид тестирования?
Сначала ответьте на вопрос: “Действительно ли на данной фазе проекта юзабилити-тестирование будет необходимо?”. С помощью этого вы сможете понять реальные цели обращения команды проекта. Главное – поймите на старте, какие именно выгоды тестирование принесет для вашего конечного продукта.
Мы советуем вам провести предварительное собрание с командой, чтобы объяснить им, на какие вопросы можно ответить, а на какие – нет. В определенных случаях, вы можете предложить заказчику отказаться от данного вида тестирования, в пользу альтернативных, например в пользу дневниковых исследований.
Что считают основой при составлении тестирования?
Не только текст самих заданий является сутью создания юзабилити тестирования, также, очень важным моментом будет являться – проработка целей и вопросов вместе с проектной командой. Ключевыми этапами формирования плана считаются:
Ключевые сценарии.
Под этим термином обычно понимают сценарии, которым следует пользователь, это могут быть различные заданий или юзкейсы, которые влияют на сам бизнес, или имеют связь с главной целью тестирования. Всегда проверяйте основные кейсы, даже если вы знаете в каких областях возникают проблемы. Среди них могут быть:
- Наиболее частые (например, возможность отправить фотографию в мессенджере);
- С прямым влиянием на бизнес (к примеру, взаимодействие при оплате заказа);
- Наиболее известные ошибки. Часто тестированию необходимо понять источник бизнес проблем системы. К примеру, владельца игры волнует высокий отток пользователей в течении первого получаса после запуска. Бывают кейсы, когда проблемы с продуктом уже известны проектной команде, и ваша задача собрать дополнительные детали.
Вопросы.
В команде могут возникнуть вопросы, которые требуют исследования. К таким вопросам можно отнести: “Стоит ли вводить баннер, в котором будет реклама дополнительных продуктов?”, “Понятны ли названия наших разделов?”.
Гипотезы.
Обычно под ними понимают преобразованные и уже известные вопросы и проблемы команды. Самым лучшим кейсом можно считать – когда заказчик может сам предоставить гипотезы. К примеру, “Чаще всего наши клиенты выбирают оплату с телефона, с включенной комиссией, может быть, они просто не знают о лучших вариантах оплаты?” В случае, если заказчик не может самостоятельно предоставить гипотезы, но он обладает желанием проверить свой проект на понятность для пользователя – то вы должны сами сформулировать их.
Вместе с проектной командой обдумайте места, где пользовательское поведение отличается от ожидаемого. Проверьте, не вызывали ли споры дизайнерские решения, которые позже могут стать проблемой.
Проведите самостоятельный аудит, в ходе которого вы должны будете отметить возможные трудности, которые могут возникнуть у конечного пользователя, и которые вам обязательно следует проверять в процессе тестирования. Благодаря этому, вы сможете составить качественный список задач, вопрос и требуемых проверок.
Примеры ограничений также присутствуют при проверке различных концепций. Вы должно четко понимать, что от уровня детализации и готовности проекта будут зависеть реальные конечные результаты.
Соответственно, в случае если, проект минимально детализирован, а прототип практически без функционала, то степень абстракции для аудитории будет выше, а это, в свою очередь, снизить количество данных, которые будут получены в итоге.
Если вы тестируете прототип проекта – то в первую очередь обратите внимание на аспекты, которые связаны с неймингом и внешним видом иконок. Остальные проверки, например, проверки клиентского пути, будут зависеть от конкретной стадии, на которой находится проект.
Сбор данных
Сбор данных — ключевой этап, который требует тщательного планирования для будущего анализа. Обычно применяются данные методы:
Наблюдение: Респондент проходит все этапы тестирования самостоятельно, работая с продуктом по своим сценариям, или по своему усмотрению. Комментарии собираются через опрос или беседу с сотрудником, которые модерирует результаты после тестирования. Этот метод позволит наблюдать за естественным, не спланированным заранее типом поведения респондента, и проводить измерение такой метрики, как, время выполнения тестов. Однако такой подход не даст полного понимания причин поведения.
Мысли вслух: Респондент озвучивает свои мысли и дает собственную оценку при взаимодействии с интерфейсом. Этот метод раскрывает причины поведения пользователя и эмоции, но может быть менее естественным, так как не все привыкли прилюдно выражать свои мысли. Скорость прохождения заданий при этом уменьшается, но респонденты могут становиться более вдумчивыми.
Участие модератора: Такой метод прекрасно подходит для проверки прототипов, где модератор тестирования будет активно взаимодействовать с респондентом, при этом он сможет выяснить причины его действий и получить дополнительную информацию, задавая вопросы во время тестирования. С помощью данной методики вы сможете собрать наибольшее количество качественных данных, но стоит учесть, что она требует высокого профессионализма модератора.
Ретроперспектива: Первоначально юзер сам выполняет предоставленные задания, после – смотрит запись своей работы и дает комментарии, почему он повел себя именно так. Один из главных недостаток – увеличения время тестирования, но иногда этот метод можно считать оптимальным.
Выбор метода зависит от ваших предпочтений, но рекомендуется стремиться к получению достаточного объема данных, сохраняя при этом естественность поведения респондента. Например, заменять метод “Мысли вслух” на наблюдение, позволяя модератору задавать вопросы после выполнения задания. Использование ай-трекера дополнительно улучшает качество модерации, позволяя более глубоко понимать поведение респондента.
Индикаторы производительности: Измерение опыта пользователя
В контексте оценки пользовательского опыта, метрики выступают в роли количественных показателей. После проведения тестирования вы обнаруживаете ряд выявленных проблем. Благодаря метрикам, вы можете понять, насколько все хорошо или плохо функционирует и сравнить с другими проектами, или прошлыми дизайнерскими решениями.
Многообразие показателей в оценке юзабилити
Не забываем, что согласно стандарту ISO 9241-11 ключевыми свойствами юзабилити считаются удовлетворенность, продуктивность и эффективность. Вопреки разнообразию метрик, применяемых в различных проектах, они все сводятся к этим трем ключевым аспектам. Рассмотрим несколько часто используемых показателей:
Успешность выполнения задач: Мы можем использовать бинарный код для определения успешности: задача выполнена или нет. Однако предпочтительнее придерживаться методологии, предложенной Нильсеном, которая выделяет три уровня успешности:
- Задача выполнена легко — 100 % успеха;
- Были трудности, но задача выполнена самостоятельно — 50 % успеха;
- Задача не выполнена — 0%.
Например, если из 14 человек 6 легко прошли тестирование, 8 столкнулись с трудностями, а 4 не смогли выполнить задачу, то средний уровень успешности составит 58%. Эта ясная метрика эффективна, особенно при явных целях задач.
График успешности по заданиям выявляет наиболее проблемные моменты интерфейса.
Время исполнения задач: Этот показатель становится информативным при сравнении. Как оценить, насколько хорошо, если пользователь выполнил задание за 1 минуту? Без сравнения с предыдущей версией дизайна или с метриками конкурента – эта метрика бессмысленна.
Но если вы заметили уменьшение потраченного на регистрацию времени на вашем проекте, по сравнению с конкурентами, или в сравнении с прошлой версией – это хороший результат. Данная метрика может быть и совершенно бесполезна, например, если вы анализируете скорость выбора товара в интернет-магазине, т.к. пользователи, в любом случае, будут тратить разное время при выборе продукта.
Частота выявленных проблем: В каждом отчете присутствует список выявленных проблем. Количество респондентов, столкнувшихся с каждой проблемой, отражает ее частоту в рамках теста. Такую метрику стоить вводить, если пользователи выполняли однотипные задания. В противном кейсе требуется оценить не только количество столкнувшихся, но и предполагаемое количество респондентов, столкнувшихся бы при выполнении похожих задач.
Как метрики влияют на оценку удобства
В сфере проверки удобства не каждый отчет обязан включать в себя набор метрик. Процесс анализ и сбора метрик может потребовать времени, и в итоге, наложить свои ограничения на методику тестирования. Однако существуют ситуации, когда использование метрик становится просто необходимым:
Для обоснования: В больших организациях часто требуется предоставление обоснования для изменения продукта. Понятные числа, которые позволяют предоставить надежные аргументы лицам, которые принимают конечное решение.
Например, представление данных о том, что 12 из 14 респондентов сказали о проблемах при оплате заказа, или что среднее время авторизации в системе вдвое выше, чем у схожей платформе, значительно усиливает влияние результатов исследования.
Для сопоставления: Если ваш продукт оценивается в сравнении с конкурентами на рынке, метрики становятся неотъемлемой частью этого анализа. Это позволяет выявить сильные и слабые стороны различных проектов и точно определить, на какой позиции находится ваш сервис среди схожих продуктов.
Для отслеживания изменений: Метрики полезны при проверке одного и того же продукта, при внесении различных изменений. Они помогают следить за эффектом после изменения дизайна, выявить области, требующие доработок. Эти данные могут быть использованы в качестве доказательства эффективности инвестирования средств в новый дизайн или просто для оценки достигнутых целей.
Для иллюстрации и подчеркивания: Числа эффективны для визуализации главных проблем. Иногда, даже если мы не пользуемся метриками каждом аспекте теста, мы прибегаем к ним для выделения наиболее значимых мест.
Несмотря на их важность, мы применяем метрики не на всех этапах тестирования. Иногда, можно обойтись и без них, если исследователь тесно взаимодействует с командой проекта, существует взаимопонимание, и команда достаточно зрела, чтобы самостоятельно определять приоритеты в решении проблем.
Готовимся к тестированию: Ключи успешного эксперимента
Помимо выбора метода, определения метрик и разработки протокола тестирования, перед вами стоит ряд важных аспектов:
Взаимодействие с модератором: Решите, как будет осуществляться контакт с модератором. Возможно, модератор будет присутствовать в одном помещении с респондентом, что облегчит задавание вопросов. Однако следует помнить, что наличие модератора иногда влияет на поведение участника.
Временами целесообразно оставить участника тет-а-тет с продуктом, что сделает его действия более естественными. В случае необходимости, модератор может использовать аудиосвязь через мессенджер для связи с респондентом.
Формулировка заданий: Примите решение относительно того, кто будет ставить цели. Модератор может сообщать их устно, но следует учесть, что каждый раз формулировка задач может звучать по-разному. Это крайне важно, если исследование проводится разными модераторами.
Для предотвращения рисков дискоммуникации – можно обучить исследователей интерпретировать вопросы заданий одинаково или предоставлять задачи опрашиваемым на бумаге или в электронном виде. Это полезно, если используется гибкий сценарий, в рамках которого задачи определяются в процессе общения с модератором.
Создание естественного контекста: Даже в условиях лаборатории стремитесь приблизить работу с продуктом на тесте, к тем условиям, которые будут в реальной жизни. Рассмотрите, как участники будут взаимодействовать с продуктом. Например, при проверке мобильных телефонов учтите, как опрашиваемые будут их держать в руке. Имитация реальных условий использования продукта обеспечит более достоверные результаты.
Подготовка плана для заказчика: Это важнейшая стадия, вовлекающий проектную команду. Представителю от бизнеса может не потребоваться подробное понимание методологии тестирования, но ему следует видеть, какие задачи будут выполнены участниками и что именно будет проверяться. Это предоставляет возможность команде проекта внести свои идеи и гипотезы.
Также определите формат отчета: подробный отчет с данными или общий файл с наблюдениями.
Планирование отчета: Создание плана отчета перед началом тестов — отличная практика. Он должен базироваться на задачах, которые требуется выполнить, в ходе тестирования. Это позволяет проверить полноту сценария и заранее разработать подходящий формат отчета, для документации итогов. Возможно, вам хватит и обобщенного документа с результатами, а не детализированного отчета.
