Выбор метода ЮТ

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

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

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

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

  • эксперимент: пользователь взаимодействует со специально подготовленным объектом по инструкции;
  • наблюдение: мы фиксируем непосредственное поведение пользователя;
  • опрос: анкетирование или интервью.

Когда использовать

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

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

Обязательно проводите ЮТ, если:

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

На тестировании юзабилист проверяет 3 ключевых свойства интерфейса:

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

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

Виды

При модерируемом тестировании пользователь выполняет задачу под присмотром исследователя, при немодерируемом — полностью самостоятельно.

 

Модерируемое ЮТ

Немодерируемое ЮТ

Инструменты

Прототип

Прототип

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

Активное участие
исследователя на этапах

Подготовка
Рекрутинг
Проведение
Анализ результатов

Подготовка
Рекрутинг

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

Количество респондентов

5-7

Ограничено размером репрезентативной выборки

Опросный метод

Интервью

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

Тип получаемых данных

Преимущественно качественные

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

Преимущественно количественные

Дополнительно можно предусмотреть открытые вопросы в анкете или использовать программы записи голоса, чтобы собрать качественные данные

Присутствие модератора на тестировании позволяет:

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

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

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

Вопросы, на которые ЮТ не отвечает

Купят или нет?

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

Как приоритезировать задачи продукта?

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

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

Удобен ли контрол, элемент дизайна или страница интерфейса?

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

Риски, если не проводить ЮТ

Без тестирований на пользователях команда рискует сделать неудобный продукт и как следствие:

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

Оцените риски и поймите, готовы ли продукт и команда их понести.

Что делать, если есть препятствия для проведения

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

Что можно сделать:

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

Когда можно обойтись без ЮТ

Вы можете не проводить ЮТ, если выполняются два условия:

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

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

    • сценарий редкий;
    • изменения небольшие и ключевые сценарии не задеты.

Если есть сомнения в решении, лучше проверить их с пользователями.