Вы делаете продукт для 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 помогает увидеть, где теряется время: оценка приоритета, поиск владельца, корреляция сигналов. Это даёт ясные гипотезы и метрики успеха, связанные с результатом восстановления сервиса.

Проверь себя · 1/3разбор после ответа
Какой признак указывает, что persona сделана неудачно и не поможет улучшать user journey?
Тренировать продукт в Telegram

Ещё вопросы по теме «Исследование пользователей и JTBD»