Исследование пользователей и JTBD: вопросы для собеседования (часть 4)
Jobs To Be Done, Customer Journey Map, пользовательские интервью — качественные методы исследования, которые дополняют количественную аналитику. На собеседовании спрашивают, когда количественных данных недостаточно и как спланировать исследование. Аналитик, совмещающий квант и квал, видит полную картину.
Вопросы 16–20 из 20
16Какая формулировка ближе всего к шаблону `JTBD` в стиле когда/хочу/чтобы и помогает отделить проблему от решения?
AСделать автозаполнение формы адреса.
BПользователи ненавидят вводить адрес.
CКогда я оформляю доставку на новом месте, хочу ввести адрес без ошибок за минуту, чтобы заказ пришёл туда, куда нужно.
DНужно повысить конверсию чекаута.
Ответ: Формат `JTBD` связывает `context` и ожидаемый результат, не фиксируя конкретную фичу.
Автозаполнение — это только один вариант решения, но проблема может быть шире: ошибки, непонятный формат, длинная форма. Формулировка когда/хочу/чтобы задаёт критерий успеха и помогает генерировать альтернативы. Её проще проверять в интервью: действительно ли люди страдают от времени и ошибок, и в каких ситуациях. Метрики бизнеса лучше привязывать к `outcome` после уточнения `JTBD`.
17У вас 30 разных просьб пользователей: предзаказ, избранное, фильтры, чат. Какой способ обработки запросов лучше всего соответствует `JTBD` и помогает строить сегменты по потребности и `context`?
AСортировать просьбы по количеству упоминаний и делать топ-5 фич.
BСгруппировать просьбы по `JTBD` и `context` (какую работу люди пытаются сделать), затем для каждого кластера описать `user journey` и ключевые `pain point`.
CСобрать все просьбы в один большой `user journey` и закрывать по очереди.
DСегментировать пользователей по возрасту и сделать фичи для самого крупного возраста.
Ответ: В `JTBD` важно группировать сигналы по `job` и `context`, а не по формулировкам фич.
Разные просьбы могут быть разными решениями одной и той же работы, например планирование покупки или снижение неопределённости. Кластеризация по `JTBD` помогает понять, какие сценарии действительно важны, и не раздувать продукт случайным списком фич. Далее `user journey` показывает, где люди застревают и какой результат не достигают. Такой подход также делает компромиссы по ресурсам и эффекту более явными.
18У продукта есть два разных `JTBD`: быстро оплатить счёт сейчас и свести расходы за месяц. Как правильнее работать с `user journey` и `pain point` в такой ситуации?
AСделать два отдельных `user journey` по разным `context` и ожидаемым результатам, и искать `pain point` отдельно для каждого.
BСделать один общий `user journey` на всех пользователей, иначе будет слишком сложно.
CВыбрать только один `JTBD`, второй игнорировать, чтобы не распыляться.
DСначала нарисовать экраны, а затем подогнать под них `JTBD`.
Ответ: Разные `JTBD` часто означают разные пути к результату, поэтому лучше строить отдельные `user journey`.
Сценарий срочной оплаты и сценарий месячной аналитики запускаются разными триггерами и имеют разные критерии успеха. Если смешать их в один путь, вы потеряете точность и не поймёте, где именно возникает `pain point`. Отдельные карты помогают сравнить, какие этапы общие, а какие уникальные. Затем можно искать общие решения, но не смешивать исследования на старте.
19Вы делаете продукт для `on-call` инженеров, которым приходят алерты. Какая формулировка лучше всего описывает `JTBD` и предполагаемый `user journey`, чтобы найти `pain point`?
AИнженер хочет красивый дашборд с историей алертов; `user journey`: открыл дашборд → посмотрел графики → закрыл. `JTBD` — видеть метрики команды в одном месте.
BВ `context` инцидента ночью инженер хочет быстро понять серьёзность, локализовать причину и восстановить сервис; `user journey` включает: получил сигнал → оценил → проверил данные → применил фикс → убедился в восстановлении.
CВ `context` дежурства инженер хочет получать меньше ложных алертов; решение — добавить фильтры и пороги, чтобы снизить шум до приемлемого уровня.
DИнженер хочет быстро связаться с командой при инциденте; `user journey`: получил алерт → написал в чат → дождался ответа коллег → совместно решили проблему.
Ответ: Хороший `JTBD` включает `context` и ожидаемый результат, а `user journey` раскладывает путь до него и выявляет `pain point` по шагам.
В инцидентах ключевые ограничения — время, стресс и неполная информация. Если начинать с решений вроде дашборда или чата, можно промахнуться мимо основного `JTBD`. Разложение `user journey` помогает увидеть, где теряется время: оценка приоритета, поиск владельца, корреляция сигналов. Это даёт ясные гипотезы и метрики успеха, связанные с результатом восстановления сервиса.
20После 6 интервью вы услышали: пользователи хотят больше фильтров. Какое действие наиболее корректно в рамках `JTBD` и работы с `pain point`, прежде чем строить решение?
AСразу добавить 10 фильтров, потому что пользователи попросили.
BСделать опрос и спросить, нужны ли фильтры, с вариантами да или нет.
CИгнорировать, потому что 6 интервью — мало и выводы невозможны.
DПонять, какой `JTBD` люди пытались сделать, в каком `context` фильтры помогают, где в `user journey` возникает `pain point`, и проверить гипотезу на данных или прототипе.
Ответ: Запрос на фичу нужно перевести в `JTBD`, `context` и `pain point`, а затем проверить влияние на результат.
Фильтры — это возможное решение, но причина может быть в плохом поиске, непонятных категориях или отсутствии нужных атрибутов. Если уточнить работу пользователя и шаг, где он застревает, можно выбрать минимальное и правильное решение. Затем гипотезу полезно проверить прототипом, аналитикой по `user journey` или тестом. Это снижает риск сделать тяжёлую фичу, которая не улучшит результат пользователя.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика