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