Павел Шерер продолжил серию статей об объединении фреймворков JTBD и Personas (с User story) в одном процессе проектирования.

— Находим контекст напряжения и потребность → Формулируем Job story → Понимаем уровень цели → Проверяем важность работы и удовлетворённость текущими решениями → Определяем акторов и персон → Выбираем механику → Пишем User story → Проверяем результат;
— Если начинаете с User story, скорее всего, вы уже выбрали механику. Но почему она лучше альтернатив? И нужна ли она конкретному пользователю?
— В JTBD интересует момент, в котором привычный способ действия перестаёт справляться с задачей;
— Нормальная Job story: когда я возвращаюсь к проекту после нескольких дней отсутствия, я хочу быстро понять, что изменилось, чтобы уверенно участвовать в обсуждении и принимать решения;
— Для каждой Job story полезно зафиксировать: какой верхний принцип или желаемое состояние за ней стоит; какое действие должен уметь выполнять пользователь; какое наблюдаемое последствие подтверждает успех; где заканчивается цель и начинается выбранная механика;
— Но, возможно, это редкая проблема, звучит страшно, но почти не влияет на поведение, достаточно хорошо решается текущим способом. Здесь пригодится Opportunity landscape;
— У конкретной персоны могут быть конкретные требования к предлагаемому решению;
— Что фиксировать в персоне: роль в работе, права и ограничения, уровень компетенции, частоту сценария, риски, за которые человек отвечает, критерии успеха, привычные инструменты, страхи и барьеры переключения, отношение к автоматизации, что персона не будет делать ни при каких условиях (особенно важно в B2B);
— Persona: продакт-менеджер, который ведёт несколько параллельных проектов, регулярно переключается между ними и отвечает за продуктовые решения;
— Выбранная механика: сводка изменений, принятых решений и новых рисков за выбранный период со ссылками на источники;
— User story, связанная с Job story, Persona и выбранной гипотезой решения: как продакт-менеджер, который ведёт несколько проектов, я хочу получить сводку изменений, решений и рисков за выбранный период, чтобы восстановить контекст за десять минут до встречи и проверить важные выводы по первоисточникам;
— С такой User story понятно: откуда появилась потребность, для кого создаётся решение, почему выбрана именно эта механика, какой результат считается успехом, какие ограничения нельзя потерять по дороге.

#user_story #job_story