#term #JTBD
Jobs To Be Done (JTBD) — концепция, один из случаев Design-Driven проектирования, кто-то даже называет это фреймворком. Это подход к исследованию целевой аудитории (боли, желания, контекст) и к созданию продукта, призывающий фокусироваться НЕ на портрете пользователя (как в методе персон/персонажей + user stories), а на проблеме, которую человек решает (хочет решить), при определенных условиях (контекст).
Данная концепция декларирует правила описания потребностей ЦА в виде Job stories.
_ _ _
Есть мнение, что метод персон/персонажей не совсем подходит для выработки стратегии развития продукта, но может познакомить команду с характеристиками целевой аудитории — это не всегда валидно для разработки заказного ПО (т.к. в этом случае удобнее все-таки декомпозировать требования на User stories map и доводить их до логического завершения и соответствия спецификациям).
_ _ _
User stories vs Job stories
• User stories фокусируются на атрибутах и характеристики персоны (чаще всего физические), а Job stories фокусируется на мотивации/чувствах, контексте/обстоятельствах и результатах — на решении проблемы в данный конкретный момент в контексте конкретных обстоятельств.
• User stories фокусируются на текущей ЦА, а Job stories в целом на проблемах (как у текущей ЦА, так и у гипотетической — больше инсайтов — полезнее для продукта)
Типичный шаблон User story: As a <type of user>, I want to <action/some goal> so that <outcome>
Типичный шаблон Job story: When <situation> I want to <motivation> So I can <outcome>
Отличий на самом деле еще очень много и всё зависит от ситуации.
_ _ _
Почитать по теме:
— Анна Булдакова о концепции Jobs To Be Done: Что это? Для кого? Как?
— Развитие – это суть концепции Jobs to be Done
— Гайд по JTBD: книги, статьи, видео
Jobs To Be Done (JTBD) — концепция, один из случаев Design-Driven проектирования, кто-то даже называет это фреймворком. Это подход к исследованию целевой аудитории (боли, желания, контекст) и к созданию продукта, призывающий фокусироваться НЕ на портрете пользователя (как в методе персон/персонажей + user stories), а на проблеме, которую человек решает (хочет решить), при определенных условиях (контекст).
Данная концепция декларирует правила описания потребностей ЦА в виде Job stories.
_ _ _
Есть мнение, что метод персон/персонажей не совсем подходит для выработки стратегии развития продукта, но может познакомить команду с характеристиками целевой аудитории — это не всегда валидно для разработки заказного ПО (т.к. в этом случае удобнее все-таки декомпозировать требования на User stories map и доводить их до логического завершения и соответствия спецификациям).
_ _ _
User stories vs Job stories
• User stories фокусируются на атрибутах и характеристики персоны (чаще всего физические), а Job stories фокусируется на мотивации/чувствах, контексте/обстоятельствах и результатах — на решении проблемы в данный конкретный момент в контексте конкретных обстоятельств.
• User stories фокусируются на текущей ЦА, а Job stories в целом на проблемах (как у текущей ЦА, так и у гипотетической — больше инсайтов — полезнее для продукта)
Типичный шаблон User story: As a <type of user>, I want to <action/some goal> so that <outcome>
Типичный шаблон Job story: When <situation> I want to <motivation> So I can <outcome>
Отличий на самом деле еще очень много и всё зависит от ситуации.
_ _ _
Почитать по теме:
— Анна Булдакова о концепции Jobs To Be Done: Что это? Для кого? Как?
— Развитие – это суть концепции Jobs to be Done
— Гайд по JTBD: книги, статьи, видео
Tilda.Education
Новый подход к работе с аудиторией
Что такое Jobs To Be Done, как правильно определить ваших конкурентов и понять мотивации ваших пользователей.