Фреймворки для планирования продуктовых и UX исследований.

Задача исследователя — отвечать на вопросы бизнеса.

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

“Ассоциируется ли сайт с нашим брендом?”

“Вырастет ли НПС, если мы сделаем этот виджет?”

“Новое отображение настроек лучше старого, или хуже?”

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

Операционализация

Иногда заказчик просит оценить абстрактную сущность. Например: “Новый сайт лучше старого?”, или “Дизайн этих плакатов отражает наш бренд?”. С такими запросами сложно работать, потому что не понятно, что значит “быть лучше старого” и что значит “отражать бренд”.

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

Что значит “сайт стал лучше”? Какие сценарии для нас важны? Какие метрики для нас важны? Какие изменения должны произойти в физическом мире в результате запуска нового сайта / продукта? В зависимости от ответа способы проверки будут разными.

Стал ли сайт лучше? Операционализируем: переводим “лучше” в вопросы о физических явлениях”:

• Будут ли люди быстрее находить нужную статью? (юзабилити-тестирование или tree testing).
• Снизится ли показатель отказов? (first click или 5-second test)
• Смогу ли я доказать своему руководителю, что новый сайт лучше (исследование предпочтений руководителя)

(в скобках после каждого пункта указаны возможные способы проверки именно этой гипотезы в рамках исследования)

То же самое с брендом. Почему дизайн плакатов должен отражать бренд? Почему это важно? Что будет, если не отразит?Операционализируем: раскрываем, что заказчик вкладывает в “отражать бренд”:

• Будут ли люди понимать, что это плакаты нашей компании, даже если не увидят логотип? (5-second)
• Перенесётся ли тёплое отношение к нашей компании на плакаты? (семантический дифференциал)
• Дизайн плакатов дерзкий (независимо от того, дерзкий ли бренд, запрос заказчика может быть в этом)? (семантический дифференциал)

Общая идея проста: прежде чем делать исследование абстрактной характеристики, привяжите её к чему-то ощущаемому — метрике или конкретному поведению.

Описание этапов взаимодействия

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

“Хорош ли новый виджет?”. Чтобы ответить на этот вопрос, нам нужно посмотреть на взаимодействие с виджетом на всех этапах пользовательского пути:

• Attention. Найдёт ли пользователь виджет? Догадается ли, что он вообще существует? (юзабилити-тестирование, tree testing, тестирование ожиданий)
• First use. Понятно ли при первом взаимодействии, как его настраивать, какие данные он отображает и что он вообще значит? (юзабилити-тестирование по сценарию)
• Use. Удобно ли пользоваться виджетом на регулярной основе? Находится ли он “под рукой”? Не раздражают ли микровзаимодействия? (интервью с опытными пользователями, дневниковые исследования)
• Need help. Понятно ли, где найти справку и документацию? Понятны ли сообщения об ошибках? (юзабилити-тестирование, tree testing, анализ обращений в поддержку).

Хороша ли новая иконка приложения? Продумываем этапы взаимодействия пользователя с иконкой:

• Attention. Привлекает ли внимание? (eye-tracking, наблюдение)
• Interest. Вызывает ли желание кликнуть? (first click)
• Use. Понятно ли по иконке, что это за приложение? (опрос на тестирование ожиданий)
• Use more. Отличается ли от других, позволяет ли легко найти нужное приложение среди других иконок? (поиск иконки среди других на скорость)

Если иконку, например, нужно оценить постфактум (после запуска), то вместо методов исследования нужно будет придумывать метрики, и на этапе choose вместо first click мы будем измерять конверсию просмотров в переходы.

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

Поиск допущений в основе гипотезы

Моё любимое. Некоторые утверждения достаточно конкретны, но проверить их напрямую сложно. Зато можно попробовать найти допущения, на которых они строятся, и которые в свою очередь уже проверяемы. Если допущения верны, то верны и сами утверждения.

Стоит ли нам добавлять новую фичу? Ищем допущения в основе гипотезы:

• Есть ли клиенты, у которых есть проблема, которую эта фичу закрывает? (интервью, опрос, анализ сообществ)
• Платят ли они сейчас за решение этой проблемы? (интервью)
• Есть ли конкуренты, которые готовы предложить лучшее решение, чем мы? (конкурентный анализ)

Стоит ли выводить фильтр по цвету на странице каталога игрушек (показывать только синие игрушки)? Или лучше показывать варианты цветов уже в карточке конкретного товара (эта машинка есть в красном и синем вариантах)? Ищем допущения в основе:

• Часто ли бывает, что цвет является самой важной характеристикой при выборе товаров, напр., ищут только синие машинки? (интервью, анализ поисковых запросов, анализ внутренних запросов)
• Бывают ли случаи, когда пользователи массово покупают сразу много игрушек одного цвета? (анализ заказов)
• Бавает ли так, что пользователи, пришедшие по поисковому запросу с цветом (купить синюю машинку) покупали товар другого цвета? Насколько часто? (интервью, анализ поисковых запросов и покупок по ним, но трудоёмко).

Используем всё сразу.

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

Подытожим

Вот как можно структурировать сложные запросы на исследования:

1. Переводим общее понятие или запрос в физические явления или сценарии поведения пользователя (хороший сайт -> сайт, где быстро находят нужную статью).
2. Представляем процесс взаимодействия пользователя с фичей/продуктом/бизнесом, раскладываем его на этапы, и уже потом придумываем, как проверить каждый этап (хорошая иконка -> привлекает внимание, манит кликнуть, описывает содержание, узнаётся при повторном просмотре).
3. Ищем ключевые допущения в основе сценария (стоит ли добавлять фичу -> есть ли сегмент клиентов, которым она нужна + есть ли конкуренты, которые уже делают это не хуже нас).

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

Почитать по теме

• Идею фреймворков и часть самих фреймворков я позаимствовал у бизнес-консультантов. Принципы построения наглядно описаны, например, здесь https://www.youtube.com/watch?v=n-yVA56L2Jg
• Статья про Riskiest Assumption Tests — подход по проверке самого рискованного предположения, лежащего в основе вашей гипотезы. Статья мне не очень нравится, а идея классная https://hackernoon.com/the-mvp-is-dead-long-live-the-rat-233d5d16ab02
• Research questions are not interview questions — очень сильная статья о том, как готовить вопросы для интервью, она помогла мне доформулировать идею про операционализацию гипотез. https://medium.com/mule-design/research-questions-are-not-interview-questions-7f90602eb533
• Ещё про ключевые допущения — есть готовые фреймворки (у тех же консультантов) которые, по сути, являются готовыми наборами ключевых допущений для разных бизнес-ситуаций. Они гуглятся по запросам business framework, case interview framework, strategy framework и подобным. Иногда готовых наборов нет, нужно думать самому, и для меня поиск таких ключевых допущений для сложных гипотез — самая интересная часть в работе исследователя.
• Мой канал про UX исследования https://t.me/uxread