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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Риски от неверного решения минимальны или их легко и быстро исправить. Например:

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

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