Вопросы по теме «Исследование пользователей и JTBD»
Jobs To Be Done, Customer Journey Map, пользовательские интервью — качественные методы исследования, которые дополняют количественную аналитику. На собеседовании спрашивают, когда количественных данных недостаточно и как спланировать исследование. Аналитик, совмещающий квант и квал, видит полную картину.
Всего в этом разделе 20 вопросов. Каждый — с правильным ответом и кратким разбором теории. Разбито на 4 части по 5 вопросов.
Вопросы 1–5 из 20
1Вы хотите сегментировать пользователей сервиса доставки для исследований. Какой вариант сегментации лучше соответствует `JTBD`-подходу: сегменты по `context` и потребности, а не по демографии?
AЖенщины 25–34 лет из городов-миллионников с высоким доходом.
BПользователи, которые заказывают еду срочно прямо сейчас и выбирают из нескольких минут, потому что голодны и спешат.
CПользователи, использующие приложение на устройствах с iOS.
DПользователи, оформившие платную премиум-подписку.
Ответ: Сегменты, полезные для продукта, часто строятся вокруг `context` и `JTBD`, а не возраста и пола.
Два пользователя одинакового возраста могут иметь разные работы: быстро перекусить или заказать на компанию. Демография не объясняет, где у людей возникает `pain point` и почему они выбирают продукт. Сегментация по ситуации, триггеру и желаемому результату помогает выбирать сценарии и решения. Технические и монетизационные признаки могут дополнять, но не заменяют сегменты по потребности.
2Что из перечисленного лучше всего является `context` в терминах `JTBD`?
AДемографический факт: пользователю 28 лет.
BСоциальный признак: пол пользователя — мужчина или женщина.
CПоведенческий показатель: количество подписчиков пользователя в соцсети.
DСитуация: пользователь в дороге с плохим интернетом и хочет быстро оплатить счёт до посадки.
Ответ: `Context` — это обстоятельства выполнения задачи: место, время, ограничения и триггер.
В `JTBD` один и тот же человек может вести себя по-разному в разных обстоятельствах. Например, оплата дома и оплата на ходу — разные ситуации с разными рисками и ожиданиями. Демография сама по себе редко объясняет причины поведения и `pain point`. Описание `context` делает выводы исследования применимыми к продуктовым решениям.
3Пользователь пишет: «добавьте кнопку повторить заказ». Какая формулировка лучше всего описывает `JTBD` с учётом `context` и желаемого `outcome`?
AКогда я заказываю обед в офисе и времени мало, хочу повторить прошлый заказ в пару действий, чтобы быстро получить еду и не отвлекаться.
BДобавить кнопку повторить заказ на экране истории.
CСделать API для повторного заказа и обновить документацию.
DУвеличить конверсию в заказ за счёт новой кнопки.
Ответ: В `JTBD` важны ситуация (`context`) и результат (`outcome`), а не конкретная фича.
Запрос про кнопку — это предложенное решение, а не описание работы пользователя. `JTBD` фиксирует, что человек пытается сделать в конкретной ситуации и почему это важно. Такая формулировка помогает сравнивать разные решения: повтор заказа, шаблоны, умные рекомендации. Технические детали и метрики полезны, но они не заменяют понимание задачи пользователя.
4Какое утверждение лучше всего сформулировано как `pain point` на этапе `user journey` поиска товара?
AНа поиске пользователи часто получают нерелевантные результаты и тратят время на прокрутку, поэтому не находят нужный товар и не достигают результата покупки.
BНеобходимо реализовать фильтр по брендам на странице поиска, чтобы сузить выдачу.
CПользователям нравится быстрый поиск, и они хотят видеть больше умных рекомендаций на главной странице.
DСледует провести редизайн страницы поиска с обновлённой визуальной иерархией и новыми компонентами.
Ответ: `Pain point` описывает препятствие в `user journey` и последствия для результата, а не конкретную фичу.
Добавить фильтр или сделать редизайн — это варианты решения, но они могут быть лишними, если причина в данных или ранжировании. Хороший `pain point` фиксирует наблюдаемую проблему: нерелевантность, время, срыв цели. Тогда можно сравнивать разные решения и измерять улучшение через достижение результата. Такая формулировка помогает команде согласовать, что именно считается проблемой.
5Какой признак указывает, что `persona` сделана неудачно и не поможет улучшать `user journey`?
AУ `persona` есть цель и критерий успеха.
BВ `persona` описаны типичные задачи и ограничения.
CВ `persona` указаны основные `pain point` и `context` выполнения задач.
D`Persona` состоит почти только из демографии и вкусов, без `JTBD`, сценариев и причин поведения.
Ответ: Слабая `persona` — это демографический портрет без `JTBD`, `context` и `pain point`.
Возраст и хобби редко объясняют, где пользователь застревает и что ему важно. Рабочая `persona` должна помогать принимать решения: что упростить, что объяснить, где добавить уверенность. Если `persona` не связывает поведение с задачами и ситуацией, команда начинает спорить о стереотипах. Поэтому в `persona` важно держать фокус на целях, контексте и болях.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика