Формулировка гипотез для юзабилити-тестирования: на что обратить внимание
В Контуре UX-исследователи часто обучают новичков исследованиям как внутри компании, так и на внешних курсах.
Одна из базовых тем любого обучения исследованиям — формулирование гипотез. Гипотезы — это предположения, которые мы хотим проверить в ходе исследования. Хорошо сформулированные гипотезы позволяют провести исследование, которое принесет пользу и ответит на вопросы от команды продукта.
Гипотезу можно считать «хорошо сформулированной», когда она краткая, понятная, конкретная и проверяемая. Сперва кажется, что сформулировать предположение с учетом этих критериев легко, но это впечатление обманчиво.
Я выделила наиболее распространенные ошибки в формулировании гипотез и подготовила рекомендации, которые помогут их избежать. В статье расскажу, на что обратить внимание, если вы формулируете гипотезы для юзабилити-тестирования (ЮТ).
Избегайте слов быстро / медленно / легко
Трактование этих слов и подобных — субъективно. Если использовать подобные абстракции в формулировке гипотезы, вы не сможете объективно оценить поведение пользователя и, как следствие — сделать однозначный вывод о результате проверки.
Что с этим делать
Если вам важен факт достижения пользователем результата, эти слова можно просто убрать из формулировки.
Пример
🤔 Пользователь легко найдет раздел «Помощь»
😍 Пользователь найдет раздел «Помощь»
При этом подробности о том, легко или сложно было пользователю, не потеряются. Вы сможете рассказать о них уже с опорой на факты для иллюстрации результата проверки гипотезы. Так вы уйдете от субъективности к конкретике и подкрепите результат проверки гипотезы в глазах команды.
Если вам все же важно проверить абстракцию — легко / сложно, — договоритесь с командой о том, что вы вкладываете в это понятие.
Пример
🤔 Пользователь легко найдет раздел «Помощь»
😍 Пользователь легко найдет раздел «Помощь»
легко = пользователь сразу нажал нужную кнопку
сложно = пользователь прошелся сверху вниз по странице, попробовал перейти на другую, не нашел, что искал, вернулся и только после этого нажал нужную кнопку
Если вам важно знать скорость работы в интерфейсе, обозначьте конкретное время.
Пример
🤔 Пользователь быстро найдет раздел «Помощь»
😍 Пользователь найдет раздел «Помощь» за 30 секунд
Никаких обобщений
Если ваша гипотеза будет «про всех пользователей» или «про работу сервиса в целом», то вы не сможете оценить, подтвердилась она или опроверглась. Например, «Пользователи не понимают, как работает сервис». Часть механики работы сервиса может быть понятна, а часть — нет. Один пользователь может быть глубоко погружен в механику, а другой — понимать общую суть. В каком из этих случаев мы будем считать гипотезу подтвержденной?
Что с этим делать
Чаще всего за общим предположением стоит конкретная проблема. Вспомните, какие сомнения / возможности и пр. подтолкнули вас к этому предположению. О каких частях интерфейса или механики работы в продукте вы вспоминаете, глядя на гипотезу? Конкретизируйте гипотезу.
Пример
🤔 Пользователи не знают возможности сервиса
😍 Пользователи не понимают, что для начала работы в сервисе нужно указать ИНН
😍 Пользователи не понимают, что автоматический расчет произойдет только после ввода процента комиссии
Избегайте «вкусовщины»
Речь о гипотезах, в которых вы предполагаете, что пользователь сможет что-то найти на свой вкус — мероприятие, объект, товар и пр. Например, «пользователь найдет подходящее платье». В проверке таких предположений есть риск, что респонденту ничего не придется по вкусу.
Что с этим делать
Если приземлять такую гипотезу конкретно на интерфейс, то чаще всего нас интересует, заметит ли пользователь разделение на категории / возможность фильтров и пр. и помогут они в достижении его цели.
Пример
🤔 Пользователь найдет подходящее платье
😍 Пользователь сможет отфильтровать выдачу в соответствии с определенными критериями
Помните: 1 гипотеза = 1 предположение
Один из признаков несоблюдения этого принципа — использование «и», «а» и прочих союзов. Если вы обнаружили подобные формулировки, то скорее всего вы заложили в гипотезу несколько разных предположений. При проведении ЮТ высока вероятность того, что одно подтвердится, а другое нет.
В результате этого при подведении итогов вам придется сказать нечто вроде «Гипотеза частично подтвердилась». При этом при рассказе подробностей — как вели себя пользователи, что их сбивало, как можно улучшить интерфейс и подобных, — придется каждый раз уточнять, к какой из частей гипотезы они относятся. Это может запутать вас и точно запутает команду.
Что с этим делать
Сформулируйте эти предположения как отдельные гипотезы.
Пример 1
🤔 Новые пользователи не смогут найти справку, а старые уже привыкли и найдут
😍 Новые пользователи не найдут справку
😍 Старые пользователи найдут справку
(не забудьте договориться, кого вы понимаете под новыми пользователями, а кого под старыми)
Пример 2
🤔 Пользователи не поймут, как отфильтровать жанры, и будут искать нужный в общем списке
😍 Пользователи не поймут, как отфильтровать жанры
😍 Пользователи будут искать нужный жанр в общем списке
Убедитесь, что гипотеза проверяема в рамках ЮТ
Иногда по верхнеуровневым данным на старте становится понятно, какой нужен будет метод. Если вы проработали гипотезы уже держа в голове ЮТ, проверьте получившийся список — это позволит своевременно определить, что нужно продумать вопросы для мини-интервью в начале или конце встречи с респондентом.
Что с этим делать
Просмотрите итоговый вариант каждой гипотезы, проверьте, о чем она: об интерфейсе или все же об опыте или сценарии респондента? Если второе, то важно запланировать мини-интервью и сформулировать вопросы для ее проверки.
Пример
🏁 На старте гипотеза звучала так:
Пользователи не знают возможности сервиса
🚩 После доработки получили две конкретных гипотезы:
Пользователи контролируют расходы
Пользователи найдут раздел Контроль расходов
В ЮТ мы сможем проверить, найдет ли пользователь нужный раздел, но давая задание мы уже исходим из того, что у респондента есть такая жизненная задача. Чтобы определить, контролирует ли он расходы уже сейчас, важно до перехода к тестированию узнать подробности о сценарии работы респондента.
Учитывайте ограничения метода
Хотя мы стараемся воссоздать в тестировании максимально реальные условия и атмосферу, а легенду и задания сформулировать как жизненные задачи, нельзя забывать, что условия работы в большинстве случаев остаются искусственно созданными.
Что с этим делать
Если окружающая среда респондента специфична и ее сложно или невозможно воссоздать на ЮТ, например, подразумевает большое число раздражителей — шум, взаимодействие с другими людьми и тому подобное, — подумайте, есть ли возможность провести ЮТ на территории пользователя. Например, если наш продукт — касса, попробуйте договориться с пользователями на встречу в их магазине.
Если давление внешних обстоятельств в реальных условиях слишком высоко — подумайте, есть ли возможность получить ответы на ваши вопросы другим способом. Например, если наша гипотеза «Будучи за рулем пользователи не могут выбрать нужный объект в приложении навигатора» — можно попробовать вместо ЮТ обратиться к данным веб-аналитики.
Резюме
- Избегайте слов быстро / медленно / легко
- Никаких обобщений
- Избегайте «вкусовщины»
- Помните: 1 гипотеза = 1 предположение
- Убедитесь, что гипотеза проверяема в рамках ЮТ
- Учитывайте ограничения метода
