Эта статья — короткая шпаргалка для тех, кто хочет проводить юзабилити‑тесты осознанно. Гипотеза в юзабилити‑тестировании — это проверяемое предположение о поведении пользователя или возможной проблеме в интерфейсе. Её можно подтвердить или опровергнуть на сессии с реальными людьми — именно она помогает держать фокус исследования. Гипотеза задаёт рамки: что именно проверяется и по каким признакам принимается решение, подтверждается ли проблема или предположение о поведении пользователя.
Гипотезы формулируются на основе аналитики, обратной связи от пользователей или наблюдений команды. Очень важно, чтобы они были связаны с целью исследования.
Примеры гипотез:
— Пользователи не могут завершить покупку из‑за того, что не понимают, как изменить пункт выдачи.
— Пользователи не замечают кнопку фильтров на странице товаров.
?Важно: гипотеза формулируется не ради самой формулировки, а под конкретную цель исследования (например, «изучить процесс оформления доставки пользователем»).Гипотезы формулируются на основе аналитики, обратной связи от пользователей или наблюдений команды. Очень важно, чтобы они были связаны с целью исследования.
Условно гипотезу (в контексте юзабилити‑тестирования) можно представить в виде формулы:
Субъект
Группа пользователей, для которых актуально предположение проблемы. Это могут быть, например, «новые пользователи приложения» или «пользователи, оформляющие заказ». Но, как правило, используется просто «Пользователь» или «Пользователи» без каких‑либо уточнений.
Предположение проблемы
Описание того, что конкретно может вызывать проблему у пользователей.
Альтернативный способ — формулировать в положительном ключе, сразу фиксируя «норму» поведения: «Субъект + успешно выполняет действие». Пример: «Пользователи замечают кнопку фильтров на странице товаров».
Преимущество положительной формулировки — нет «двойного отрицания» на разборе результатов. Если мы оставим отрицательный вариант («Пользователи не замечают кнопку фильтров») и по итогам теста он не подтвердится, приходится проговаривать «не подтвердилось, что не замечают» — считывается тяжело. А если подтвердится, то звучит парадоксально: «гипотеза подтвердилась», хотя сама она про проблему. В положительном варианте всё прямолинейно: «подтвердилась» — значит, всё ОК; «не подтвердилась» — значит, есть что исправлять.
Всем удобно по‑разному: кому‑то ближе «проблемная» формулировка, кому‑то — положительная. Главное — выбрать единый подход для конкретного исследования и последовательно держаться его в сценариях и отчёте, чтобы не путать интерпретацию результатов.
Далее необходимо разобрать основные принципы, которые помогут формулировать гипотезы:
Принцип 1 — Конкретность и фокус на проблеме
Гипотеза должна чётко описывать, какую именно проблему пользователя вы предполагаете.
❌ Пример плохой гипотезы:
«Пользователи не понимают условия доставки товара».
В «условия доставки» может входить множество параметров: стоимость, сроки, курьер/самовывоз. Поэтому гипотеза не очень конкретна.
✅ Пример хорошей гипотезы:
«Пользователи не замечают срок доставки товара до пункта самовывоза».
Данная гипотеза уже имеет конкретные фокусы на сроке и типе доставки.
Полезно добавить к гипотезе «триггеры наблюдения»: что именно на сессии будет сигналом проблемы? Например: «переспрашивает у модератора», «возвращается назад более двух раз», «зависает на экране > 20 секунд».
Принцип 2 — Основание на данных и наблюдениях
Желательно, чтобы гипотеза строилась на основе предварительных исследований, аналитики, пользовательских отзывов или наблюдений. Это помогает избежать произвольных предположений. Но при этом допустимо, чтобы сомнения дизайнера, исследователя или команды в целом по отношению к интерфейсу были сформулированы в виде гипотез.
Источники гипотез:
— Посмотрите аналитику и узнайте, на каких страницах или этапах воронки пользователи уходят. Это является сигналом к тому, что на них может быть что‑то не так с интерфейсом.
— Пройдите путь пользователя на сайте самостоятельно — вы наверняка найдёте то, что вызывает затруднение или может выглядеть сомнительно.
— Спросите у других членов команды, что, на их взгляд, может вызывать трудности у пользователей.
— Если у вас подключён Яндекс.Вебвизор (позволяет записывать видео реальной сессии пользователя на сайте) или его аналог, посмотрите сессии пользователей — они могут натолкнуть на то, с какими проблемами сталкиваются пользователи при взаимодействии с интерфейсом.
— Обращения в поддержку, которые касаются интерфейса.
— Комментарии к опросам NPS и CSAT, отзывы в сторах.
Принцип 3 — Проверяемость
Гипотеза должна быть сформулирована таким образом, чтобы можно было собрать данные, подтверждающие или опровергающие её.
❌ Пример непроверяемой гипотезы:
«Интерфейс неудобен для пользователя».
Гипотеза абсолютно неконкретна, и нет критерия, по которому возможно опровергнуть или подтвердить гипотезу. С помощью такой формулировки невозможно понять, что именно не так с интерфейсом.
Или же гипотеза может проверяться другим методом, отличным от юзабилити‑тестирования: «Демонстрация числа пользователей, уже купивших конкретный товар в карточке товара, увеличит CR в покупку на 15%».
Эту гипотезу невозможно проверить с помощью юзабилити‑теста — необходимо использовать A/B‑тестирование, а это совершенно другой метод исследования.
Юзабилити-тесты отвечают на вопрос «может ли пользователь выполнить задачу и что ему мешает», но как это скажется на конверсии или покупках этим методом не оценить . Поэтому эффект на CR проверяют, например, A/B-тестом на реальном трафике: сравнивают контроль и эксперимент и считают статистическую значимость.
Кроме гипотезы в виде предположения о наличии проблемы, можно формулировать гипотезы в виде утверждения о возможных действиях пользователя, чтобы проверять то, как действуют пользователи.
Например, у нас есть вопрос: как пользователь будет добавлять товар в корзину?
Гипотеза 1:
«Пользователь нажимает кнопку „Добавить в корзину“ прямо на карточке товара в списке каталога».
Гипотеза 2:
«Пользователь переходит в детальную карточку товара, где затем нажимает кнопку „Добавить в корзину“».
Формулировка «как будет действовать пользователь» полезна, когда у вас несколько конкурирующих паттернов. По результатам проще выбирать приоритетный сценарий и урезать «шум» интерфейса.
? Совет. Обязательно анализируйте получившиеся ранее гипотезы: возможно, не все из них реально проверить с помощью юзабилити‑тестирования, и для части стоит подобрать другие, более релевантные методы исследования.
Примеры гипотез:
«Пользователи не видят кнопку „Сохранить“ после редактирования профиля».
«Пользователи не понимают, как применить фильтр по бренду в каталоге товаров».
«Пользователи не могут найти раздел „Избранное“ на главной странице мобильного приложения».
«Пользователи не могут восстановить пароль, потому что не видят ссылку „Забыли пароль?“ на странице входа».
«Пользователи не понимают, как изменить количество товара в корзине».
Хорошая гипотеза держит исследование в рамках: что именно проверяем и как понимаем результат. Формулируйте коротко и предметно, опирайтесь на данные и наблюдения, фиксируйте критерии подтверждения заранее. Используйте тот вариант записи, который вам удобнее — «проблемный» или положительный — и придерживайтесь его на всём протяжении исследования, чтобы избежать путаницы при разборе.
Если хотите начать карьеру в UX-исследованиях или уже делаете первые шаги, загляните в мой Telegram-канал. Там я делюсь полезными материалами, примерами хорошего и плохого UX, а ещё — вакансиями и стажировками для джунов.