Моя бабушка сечёт в интерфейсе консоли, или Что важно знать про гипотезы для usability-теста

Гипотезы для UX-тестов — это один из самых быстрых, простых и доступных способов тестирования интерфейсов. Хорошая проработка гипотез во многом залог успешного исследования, так как именно исходя из гипотез:

• выбирается метод исследования;
• планируется сценарий исследования;
• определяются границы исследования.

Я хочу поделиться опытом подготовки гипотез для исследования в нашей команде UI/UX, где рождается дизайн всех продуктов Kaspersky. Расскажу, как именно мы используем этот метод, но главное — кто должен придумывать гипотезы, откуда их брать и как придумать хорошую. 

Мария Нефедьева

UX-исследователь в команде Design & Research «Лаборатории Касперского»

Вместо дисклеймера замечу, что все критерии «хороших» и «плохих» гипотез актуальны и для других типов исследований, однако в usability-тестах есть своя специфика, поэтому мы будем разбирать на их примере.

Для начала договоримся, что такое гипотезы и зачем они нужны, потому что научное определение одно, а его практические толкования для разных профессий могут плавать. Итак, согласно книге «Социологическое исследование: методология, программа, методы» «гипотезы — обоснованные предположения о структуре объектов, характере связей между изучаемыми явлениями и возможных подходах к решению социальных проблем».

А теперь простыми словами ?

Гипотезы — предположения о тестируемом объекте (интерфейсе и т. д.), о том, почему и как с ним взаимодействует пользователь, которые необходимо проверить для достижения цели исследования.

С терминологией и областью применения разобрались, но как с ними работать на практике?

Кто должен придумывать гипотезы

Здесь нет правильного ответа. Расскажу о том, как это делаем мы.

В Kaspersky исследования проводятся внутри рабочих групп, состоящих из: заказчика исследования (обычно это продакт-менеджер), дизайнера, маркетинг-менеджера, технического писателя и, конечно, исследователя. Мы не ограничиваем круг лиц, которые участвуют в подготовке и обсуждениях, поэтому приложить руку к исследованию могут все, кто причастен к разработке тестируемого продукта. Каждый из участников рабочей группы готовит свой список гипотез (и даже хорошо, если у нескольких участников рабочей группы они будут одинаковые).

Почему мы так делаем

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

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

При таком способе подготовки гипотез мы:

1. Частенько дорабатываем макеты, потому что участники рабочей группы уже до тестов видят часть проблем.
2. Сильно облегчаем себе обработку результатов (дальше я расскажу почему и как) и можем процентов на 80 предугадать результаты исследования, и лишь 20 будут неожиданными инсайтами.

Откуда брать гипотезы

Именно из этого вопроса от коллег и родилась эта статья. Одно дело, когда исследователь одиноко собирает UX гипотезы в своём рабочем файлике, другое дело, когда задачу приходится делать всей команде, которая раньше могла этим никогда не заниматься.

Поделюсь чек-листом источников, которые стоит учесть:

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

Коллегам я предлагаю метод «бабушки из Урюпинска». Это собирательный образ, не в обиду Урюпинску и бабушкам, тем более что моя, например, активно ставит лайки своим подружкам в социальных сетях. В чём он заключается?

Каждому участнику рабочей группы я предлагаю абстрагироваться от накопленного в своей сфере опыта, знаний о современных технологиях и представить себя той самой «бабушкой из Урюпинска». Пройти путь пользователя как эта бабушка, каждую секунду задумываясь о том, где она может сделать или понять что-то не так.

Все эти мысли в потоке записывать в заметки, Word, куда угодно, подписав экраны, на которых эта мысль появилась. Важно быть внимательным и открытым: смотреть не только на очевидные вещи, которые запланированы сценарием, но и представлять, что ты случайно нажал куда-то не туда, свернул страницу, закрыл и т. д.

Признаться, этот способ отлично работает для B2C продуктов, и не до конца учитывает специфику B2B продуктов. Но всё же применим. Ведь почему, например, какому-нибудь системному администратору должно быть хуже, если даже бабушка просечёт интерфейс его рабочей консоли? ?

Как придумать «хорошую» гипотезу

Постараться соблюсти следующие правила:

Гипотеза должна соответствовать цели исследования

Наверное, это самое важное при подготовке гипотез. Перед исследованиями можно частенько столкнуться с ситуациями «а давайте проверим ещё вот это», «давайте узнаем ещё вот это», что не всегда соответствует цели, границам исследования и выбранному методу. Поэтому необходимо проверять, не пытаемся ли мы объять необъятное? Вероятно, для тестирования этих гипотез можно провести отдельное исследование, если это необходимо.

Не нужно создавать гипотезы ради гипотез. Для каждой решите, что будете делать, если она подтвердится. Или не подтвердится. Если с результатами проверки гипотезы ничего нельзя сделать, то от неё стоит отказаться.

Гипотеза должна быть проверяема

Мы адаптируем сценарий исследования под гипотезы и наоборот, однако случаются ситуации, когда гипотеза становится непроверяемой. Например:

• Когда мы тестируем один функционал, а гипотеза относится к другому. Например, мы проводим тестирование процесса оформления заказа в корзине, а гипотеза относится к категориям меню. Увы, эту гипотезу проверять мы не будем.
• Когда гипотеза не соответствует выбранному методу исследования.

Разные методы исследований позволяют получать ответы на разные исследовательские вопросы, это напрямую касается и гипотез.

Например, гипотеза «Новые, более крупные фото в карточке товара увеличат конверсию на 15%» — отличная, но она подходит для A/B-тестирования, а не для usability-теста, так как в них мы не можем оценивать степень чего-либо при сравнении.

Или UX гипотеза «Пользователей раздражает, если им приходит больше трёх уведомлений в день» — тоже отличная, но для дневникового исследования, потому что оценивает поведение тестируемого объекта вне рамок теста.

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

Хорошая гипотеза должна быть конкретной

Постарайтесь строить как можно более точные и однозначные гипотезы. Она должна быть сформулирована так, чтобы избежать разночтений. Как это сделать?

1. Чем более дробный шаг пути пользователя или мельче элемент интерфейса, который вы анализируете, тем лучше. 
2. Здорово, если гипотеза содержит в себе предпосылки наблюдаемого поведения.

Давайте разберём на примере покупки в Интернет-магазине.

❌«Непонятно, как оплатить заказ»

✅«Непонятно, как ввести данные новой, а не привязанной ранее карты»

Подтвердив первую UX-гипотезу, мы не знаем, что с ней делать. Да, непонятно, но в какой именно момент? Такие результаты чреваты разночтениями между участниками рабочей группы, в них легко увидеть желаемое, а не действительное. Сами понимаете, к чему это может привести.

Приведу несколько примеров неконкретных и конкретных гипотез:

Неконкретная: Пользователь не выдаст разрешение на использование геолокации.

Почему? Не поймёт, для чего оно? Не заметит этот элемент интерфейса? Не поймёт, что это именно разрешение на отслеживание геолокации? Принципиально откажется от выдачи разрешения, зная, что это сильно уменьшит возможности приложения?

Конкретная: Пользователь не поймёт, что выдача разрешения на использование геолокации необходима для корректной работы основной функции приложения.

Неконкретная: Пользователь не поймёт условия доставки.

Также неясен ряд вопросов. Не поймёт, что это доставка до ПВЗ, а не домой? Не поймёт, что привезут завтра, а не сегодня? Не поймёт, что для получения потребуется паспорт? И т. д.

Конкретная: Пользователь не заметит, что доставка платная.

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

Именно для того, чтобы формулировать конкретные UX-гипотезы мы ранее самостоятельно знакомились с тестируемым объектом и беспристрастно изучали все узкие места. Это помогает понимать, где именно могут возникнуть проблемы.

Как сформулировать гипотезу

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

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

Из гипотезы-вопроса довольно легко сделать гипотезу-утверждение. Давайте попробуем вместе.

Гипотеза-вопрос: Как пользователь увеличит количество товара для заказа?

Мы знаем, что это можно сделать несколькими способами. Именно их и формулируем в гипотезы-утверждения:

• Гипотеза-утверждение 1: Пользователь увеличит количество товара в заказе через +1 в корзине. 
• Гипотеза-утверждение 2: Пользователь увеличит количество товара через +1 в карточке товара. 
• Гипотеза-утверждение 3: Пользователь попробует добавить тот же товар в корзину ещё раз.

У нас получилось 3 гипотезы-утверждения, на которые можно ответить «да, это так» и «нет, это не так». В результате мы:

1. Заранее продумали все (или основные) пути, которыми может пойти пользователь для решения своей задачи, поэтому поведение пользователей будет для нас более предсказуемым. 
2. Это сильно облегчит дальнейшую обработку результатов.

Почему хорошо подготовленный список гипотез облегчает анализ результатов

Если вы хоть раз проводили usability-тест, скорее всего, вы знакомы с чек-листами. Для остальных расскажу про удобный и простой инструмент для работы с результатами тестов. Мы с коллегами используем для анализа Excel-таблицы, где в столбцах прописываем вопросы и гипотезы в строках номеров респондентов.

Выглядит это примерно так

Так, при заполнении этого файла достаточно ставить 0, если гипотеза не подтвердилась, и 1, если подтвердилась. Внизу после всех тестов можно посчитать сумму по всем подтверждённым гипотезам через формулу. В результате:

1. Мы легко считаем встречаемость проблем, какие гипотезы были подтверждены, а какие опровергнуты.
2. Да, подготовка такого чек-листа занимает время, но зато заполнять его быстрее. Вместо того, чтобы писать словами «вышел из корзины, снова начал искать товар и добавлять его, чтобы увеличить количество» мы просто ставим 1, где гипотеза подтвердилась, и 0, где нет. Благодаря этому, мы можем не пересматривать в записи большинство тестов.

Вот и всё, что важно знать про гипотезы для успешных тестирований. Если вам было интересно, то приходите к нам в Kaspersky в команду UI/UX — будем прорабатывать и предугадывать пользовательский опыт вместе ? Ну а если вы не только знаете, как выстраивать процесс исследований, но и умеете успешно пользоваться его результатами, а также хотите влиять на продукты на всех уровнях — от стратегии до имплементации — то, кажется, мы ждём именно вас на позицию Product Designer B2B.