Что такое Jobs-To-Be-Done и Job stories
Хочу рассказать вам про один классный фреймворк, о котором, к сожалению, знают немногие: Jobs-To-Be-Done (JTBD). Его популяризировал профессор Гарвардской школы бизнеса и автор “Дилеммы инноватора” Клейтон Кристенсен.
Суть подхода очень простая:
вот есть, к примеру, Петя. Пете 30 лет, у него жена и ребенок. Петя трудолюбивый, веселый и добрый. По выходным Петя ходит в спортзал, а раз в месяц встречается с друзьями в спортбаре.
5 минут назад Петя купил сникерс.
Повлияла ли какая-то из характеристик, перечисленных выше, на факт покупки? Нет, не повлияла. Петя купил сникерс не потому, что ему 30 лет, а потому что он проголодался.
Конечно, идея строить продукт вокруг проблемы совсем не нова (собственно, и JTBD существует уже больше 30 лет, но применялся преимущественно в производстве физических продуктов). JTBD просто дает удобный фреймворк и инструментарий для работы, вот и все. Но разница в организации команды, в построении стратегии и разработке фич — огромная.
User stories vs job stories
Даже если вы не эксперт в UX, наверняка слышали (или видели) такой шаблон:
По сути, это и есть user story — какое-то краткое описание фичи со стороны пользователя. обычно основывается на одной из ваших Персон (про Персон можно почитать подробнее здесь, если вкратце — вы проводите user researches, анализируете онлайн-данные и создаете несколько (стандартно 5–6) собирательных пользователей, которые представляют ключевые сегменты вашей аудитории).
Я, честно, несколько раз пыталась использовать Персон и user stories в работе, но постоянно сталкивалась с одними и теми же проблемами:
Не будем так уж обижать персон, в целом, это хороший инструмент, чтобы “познакомить” разработчиков с пользователями. Но для определения продуктовой стратегии и приоритизации фич подходит не очень. Вот цитата из статьи Пола Адамса, VP of Product в Intercom (а ранее работавшего в Google и Facebook):
“Whilst best in class personas focus on goals (goals are what drive people’s behaviour) as well as attributes, the reality is that most personas focus on attributes alone, and even goal-driven personas artificially break apart audiences. So critically, personas artificially limit your product’s audience because they focus on attributes rather than motivations and outcomes”.
Таким образом, мы плавно подошли к job stories, которые Intercom и изобрели. И суть в том, что фокус с персональных характеристик смещается на контекст:
As a 30-летний Петя, I want to съесть что-нибудь вкусненькое, so that я больше не был голодным.
When у меня есть всего 2 минуты, чтобы перекусить между встречами, I want to съесть что-то, чтобы это было просто, быстро и подняло мой уровень сахара в крови, so I can продержаться до обеда и сохранить рабочее настроение.
Job story в действии
Разберем теперь более подробно, как составлять job story.
Есть у нас, к примеру, спортзал, где мы хотим увеличить продажи месячных абонементов. Сначала посмотрим на персон (описание довольно условно, в реальности оно гораздо более подробно и детализированно):
В каком случае такие описания будут нам полезны?
Например, для таргетированной рекламы. Хотим мы привлечь больше Маш или Никит — пожалуйста: устанавливаем настройки кампании в соответствии с определенными характеристиками наших персон и ждем.
Годятся ли они для разработки, тем более, инновационной?
На мой взгляд, не очень. Персона — это какой-то конечный результат исследований и нашего труда; эта та аудитория, которая у нас уже есть. Ориентируясь на персоны, мы искусственно ограничиваем свой продукт, не разрабатываем фичи для новых, потенциальных пользователей. Опять же, фокусируясь исключительно на “старичках”, улучшая продукт для них, мы выпадаем из конкурентной борьбы. Почему? Потому что не думаем о других способах решения проблемы наших пользователей. Мы думаем о том, как они видят это решение, и отполировываем его — вместо того, чтобы в корне менять подход и перебирать варианты решения.
Условно говоря, мы можем построить суперсовременный спортзал с тачскринами и детским уголком — и при этом все равно “отдать” часть пользователей мобильному приложению с тренировками или домашнему велотренажеру.
Давайте вернемся к нашей Маше. Вот пример job story, который мог бы случиться:
Когда я занимаюсь спортом в зале, а у меня есть маленькие дети и мне не с кем их оставить, я хочу, чтобы они были под присмотром, чтобы я не волновалась и спокойно упражнялась в течение часа.
Важно ли тут, что Маше 30 лет? Что у нее двое, а не один ребенок? Кто она по образованию? И что вообще это Маша, а не Аня? Нет, на передний план выходит одна единственная характеристика: что у нашего пользователя есть маленькие дети. В job stories это часть контекста, а не описания пользователя — просто потому, что в контексте могут оказаться совершенно разные по профилю пользователи. В примере с детьми это может быть Маша, а может быть и Никита, если его старшая сестра уехала в командировку и попросила посидеть с детьми, а он не хочет пропускать тренировку.
Легче всего это понять на примере Uber. Вроде как уж здесь-то точно есть две конкретные персоны: водитель и пассажир. На самом же деле, эта характеристика лишь часть контекста: в зависимости от ситуации водитель может оказаться на месте пассажира, и наоборот.
Если мы говорим про магазин сладостей, и контекст “Хочу изредка побаловать себя сладким после тяжелого дня или успешного проекта”, сюда могут попасть как Маша и Никита, так и диабетик Миша, вегетарианка Алиса и сидящий на диете Петя. Мы думаем не о том, что разнит наших пользователей, а что их объединяет. Таким образом, те фичи, что мы делаем и релизим, получают больший охват.
Персоны, безусловно, гораздо лучше, чем ничего. Более того, многие успешные компании до сих пор работают с этим фреймворком и прекрасно себя чувствуют. В любом случае, job stories — это лишь еще один классный способ с другой стороны взглянуть на свой продукт. Персоны позволяют вам под лупой посмотреть на ваших пользователей, но не отвечают на вопрос, почему они продолжают пользоваться вашим продуктом — и почему придут новые после того, как вы зарелизите фичу. В моей картине мире все выглядит примерно так:
Как провести исследование для job story
Итак, допустим мы прониклись и хотим написать хорошую job story. С чего начать? Конечно, с исследования.
Большинство текущих исследований фокусируются на моменте потребления продукта, тогда как job story research пытается понять, когда и в каких условиях у клиента закралась первая мысль о покупке продукта (то есть, то, что случилось еще ДО начала его использования). Исследователь основывается на предположении, что на клиента в момент решения о покупке действуют четыре силы:
Собственно, основная задача в таком интервью — выявить эти четыре фактора. При этом очень важно понимать не только рациональные, но и эмоциональные аспекты решения (условно — “шел ли дождь, когда вы делали покупку?”):
— В какой спортзал вы ходили раньше? Откуда вы о нем узнали?
— Расскажите, какой образ жизни вы вели в то время? Часто ли испытывали стресс?
— Расскажите мне про свой прежний спортзал. Как часто вы занимались? Опишите по шагам, что происходило после того, как вы открывали входную дверь.
— Что вас особенно расстраивало в прежнем спортзале? Когда вы начали задумываться о поиске нового?
— Когда вы впервые услышали про текущий спортзал? Было ли у вас несколько опций или только одна?
— Как долго вы принимали решение о переходе? Что вас сдерживало от покупки?
И так далее. Очень важный момент: разговаривать надо не с пользователем, а с покупателем; человеком, который принял решение о покупке. То есть, вы должны интервьюировать не ребенка, которому родители купили абонемент в спортзал, а как раз родителей.
Зачем все это и что оно нам дает?
Люди инертны по своей природе. В большинстве случаев, они будут продолжать пользоваться привычным решением, чем исследовать рынок и искать что-то новое — просто потому, что им и так норм. Должно случиться что-то из ряда вон выходящее, чтобы я перестала брать кофе в своей любимой кофейне.
И очень важно понимать, что пользователи не покупают ваш продукт, они переключаются на него с чего-то еще. До нового спортзала был предыдущий спортзал. До предыдущего спортзала была зарядка на коврике по утрам. До коврика были бургеры и мороженое в макдаке (это уже непрямая конкуренция, о ней дальше). Цена переключения с одного продукта на другой определяется привычкой и степенью удовлетворенности, помноженных на страх перемен. И вам критично важно поймать этот момент внутренней борьбы и подтолкнуть пользователя в нужном направлении.
Когда “работа” продукта заканчивается
Продукты решают не изолированные проблемы, а проблемы, которые происходят в каком-то workflow: есть то, что случилось “до”, и то, что произойдет “после”. То есть, таким образом, у “работающего” продукта есть начальная и конечная точки. Вопрос в том, как их правильно определить.
Если ваш продукт делает слишком мало, в глазах пользователя он не стоит того, чтобы его устанавливать (и, тем более, платить за него). Если продукт делает слишком много, он вступит в конфликт с уже существующими элементами workflow, которые вполне устраивают пользователя.
Так где же золотая середина?
Давайте разберем на простеньком примере. Допустим, вы пишете приложение-будильник; в этом случае workflow может выглядеть так:
“Работа” вашего продукта должна начинаться с того шага, где вы можете добавить какую-то ценность для пользователя. Для нашего примера это, скорее всего, шаг 3. Мы, конечно, можем влезть и раньше: например, если пользователь обычно встает в 7 утра, а уже 12 вечера, и телефон активен, наше приложение отправит ремайндер: котик, а не хотите ли поставить будильник и пойти спать? Можем пойти еще дальше: сделать фитнес-браслет, который будет трекать пульс и активность пользователя и рекомендовать ему лучшее время, чтобы пойти спать (и будить его, соответственно, тоже в лучшее время для подъема). Нужно ли это? Испытывает ли пользователь “боль”, соответствующую масштабам исследований и разработки? Это и нужно понять и решить продуктовой команде в самом начале.
А когда же “работа” должна заканчиваться?
Конкуренция в контексте JTBD
Какое-то время назад я писала про компанию BVG, которая де-факто монополист в сфере общественного транспорта в Берлине. BVG тратит огромные деньги на рекламу — вопрос: зачем она это делает, если и так все метро, автобусы и трамваи принадлежат исключительно ей?
Если посмотреть на этот вопрос с точки зрения JTBD, ответ придет сам собой. “Работа” пользователя в этом контексте — добраться из точки А в точку Б, а не воспользоваться общественным транспортом. И тут BVG оказывается никаким не монополистом, а лишь одним из участников рынка — наравне с:
— велосипедами
— велосипедами/скутерами напрокат
— такси
— собственными автомобилями
— каршерингом
— да даже передвижением пешком.
JTBD позволяет шире посмотреть на проблемы пользователя и выявить ваших настоящих конкурентов.
Прямая и непрямая конкуренция
С прямой конкуренцией все понятно. Но есть еще один вид конкуренции, о котором все забывают.
Пример: Петя обожает бургеры и хочет питаться только ими, но в то же время Петя хочет быть мускулистым и спортивным.
То есть, условный BurgerKing и FitBit продают совершенно разные продукты и решают разные проблемы, но борются за одного и того же пользователя. Это непрямая конкуренция.
Прямая конкуренция — соперничество за “работу”
Непрямая конкуренция — соперничество за “результат”
Помните наш фреймворк для job stories?
Вот этот outcome нам и важно определить. В этом контексте Skype, например, соперничает с полетами бизнес-классом, потому что результат у них один — провести бизнес-встречу. Возвращаясь к бургерам и спорту, результат может быть “почувствовать себя счастливым/ более уверенным в себе” или “ощутить принадлежность к какой-то социальной группе”.
Определение глобального “результата” вашего продукта помогает не только правильно позиционировать себя на рынке, но и работать с конкурентами. Чтобы двигаться вперед, вы должны либо сделать “результат” другого продукта менее привлекательным в глазах пользователя, либо же изменить позиционирование продукта, чтобы “результаты” больше не находились в конфликте.
Job story: что это, как разработать, как использовать
Job story — артефакт из теории JTBD, который емко и структурированно описывает потребность человека.
К сожалению, я не знаю адекватного перевода на русский язык выражения фразы job story, чтобы оно было таким же кратким и так же хорошо описывало суть, поэтому использую английский вариант.
Job story погружает нас в контекст и состоит из трех компонентов-«кирпичиков»:
В литературе вместо «изменение» вы можете встретить термины «мотивация» и «прогресс», но я использую «изменение». Почему — об этом далее.
Структура job story
Формулируется job story в виде предложения, и это удобно делать в таком формате:
Посмотрим на каждый компонент отдельно.
Ситуация («Когда…»)
В какой ситуации находится человек, когда у него возникает проблема? Живет он, занимается своими делами — и вдруг происходит что-то, вызывающее у него желание изменений. Это что-то — проблема для человека. Если нет проблемы, то и менять никто ничего не будет: мы (люди) инертны, предпочитаем статус-кво и стремимся минимизировать усилия. Когда все в порядке, то и делать ничего не надо — пусть оно идет дальше, как шло.
Но наша задача — описать в ситуации не саму проблему, а именно контекст, в котором находится человек, когда эта проблема произошла.
Дальше буду приводить практические примеры, которые мы использовали, когда работали над продуктом для DOPE. Поэтому они будут про еду и вымышленного Колю.
Пример. «Коля голодный» — это проблема, но не ситуация. Такая формулировка не дает нам никакой практической ценности. Непонятно, что такое случилось с Колей, что он стал голодным, и почему это вообще проблема. Поэтому необходимо описать ситуацию, в которой эта проблема с Колей случилась.
Встанем на место Коли и сформулируем от его имени, например: «Когда я весь день езжу по делам на машине за рулем и не могу нормально пообедать…»
Обратите внимание: в таком описании ситуации обозначено некоторое затруднение («не могу нормально пообедать»), потенциально порождающее проблему, конфликт, но само по себе не имеющее оценки. «Не могу нормально пообедать» — это еще не проблема сама по себе. Ну не может, ну и что? Возможно, он так позавтракал, что и не хочет нормально обедать.
Поэтому наша задача:
Изменение («я хочу…»)
В литературе вместо «изменение» вы можете встретить термины «мотивация» и «прогресс» (motivation и progress в английских источниках). На мой взгляд, в русском варианте именно «изменение» более адекватно отражает суть. Мотивация в нашем понимании — это больше о результате, для чего человек что-то делает (например, решает свою проблему). А слово «прогресс» слишком сильное, хотя и корректно отражает суть. Поэтому я использую «изменение», предполагая, что нас интересует только изменение к лучшему, так как человек прилагает усилия, только когда ожидает изменений к лучшему. То же самое — решить свою проблему.
Пример. Какое изменение хочет произвести Коля, когда «весь день ездит по делам на машине за рулем и не может нормально пообедать»? Самое очевидное — «быстро утолить голод».
Результат («чтобы…»)
Результат — что получит человек в результате решения проблемы. «Перестать быть голодным» — это правильно, но не дает нам ценной информации, и с такой формулировкой мы ничего дальше сделать не сможем. Нам нужно понять, почему Коля хочет «перестать быть голодным». Для этого зададим вопрос «Чтобы что?».
«Перестать быть голодным» — «Чтобы что?» — например, «чтобы успеть сделать все дела и дотянуть до ужина».
Мы намеренно используем кривые с точки зрения русского языка выражения вроде «перестать быть голодным», потому что наша задача здесь — не найти красивые формулировки, а корректно отразить суть происходящего, не растеряв смысл.
Вот что у нас получится:
Job story контекстуален, поэтому для разных контекстов необходимо описывать разные job stories:
Некоторые правила формулирования job story
Мы стараемся конкретизировать ситуацию и результат, чтобы лучше понимать контекст, но еще не ищем решений, а только описываем изменение.
Откуда брать информацию
Есть два принципиальных источника информации: от самих потребителей и от себя.
1. Исследуем потребителей
Мы можем провести исследование, поговорив с теми, кто уже покупал, покупает регулярно или использует наш продукт.
Покупатели и пользователи не всегда совпадают, особенно в B2B, но наша задача — понимать потребности всех групп. Есть определенные методики, как искать таких людей, договариваться с ними и проводить интервью.
Для погружения в тему рекомендую книгу Роберта Фитцпатрика «Спроси маму».
Профессиональные исследователи, продакт-менеджеры и маркетологи часто говорят, что исследования — единственный достоверный источник информации, и по-другому делать не надо.
Действительно, никто не знает, что на самом деле происходит в голове у потребителя, даже он сам. Но, несмотря на это, я считаю, что позиция «только проводить исследования и больше никак» несколько оторвана от жизни. Да, в крупных компаниях (в которых, как правило, и работают продакт-менеджеры или на которые работают исследователи) это реализуемо. Исследовать потребителя — правильный путь. Но реальность не всегда совпадает с «правильностью».
В малом и среднем бизнесе или о новых продуктах часто поговорить просто не с кем, или внутри компании нет компетенции проводить такие интервью (а их надо уметь проводить) и ресурсов нанимать исследователей тоже нет или нет такого желания. Всё? Тупик? На самом деле, нет.
2. Встаем на место потребителей
Во-первых, масса информации всегда есть в голове у владельца бизнеса или других сотрудников, взаимодействующих с клиентами, только надо ее грамотно оттуда извлечь и структурировать.
Во-вторых, грамотный маркетолог все же должен обладать эмпатией и уметь вставать на место потребителя. Несмотря на известное выражение маркетологов «не мерить по себе» (а мерить по себе и правда не стоит), надо представить себя на месте потребителя, подумать, в какой ситуации и почему у него возникают проблемы, как бы он их хотел избежать и что получить в результате.
Итак, вытаскивайте информацию из собственной головы или головы владельца бизнеса, включайте эмпатию, вставайте на место потребителя и описывайте его ситуацию, желаемые изменения и результат. В любом случае, оперируете ли вы результатами исследования или собственными находками, на выходе у вас будут только гипотезы, которые еще надо проверять.
Частые ошибки при формулировании job story
«Когда я голодный, я хочу поесть, чтобы не быть голодным».
Все верно, только такая job story нам ни к чему — в ней нет ценной информации, и использовать мы ее никак не сможем. Пример утрированный, но после формулирования job story проверьте — не получилось ли вот так?
«Когда я весь день езжу по делам на машине за рулем и не могу нормально пообедать, я хочу съесть Сникерс, чтобы не отвлекаться и успеть доделать все дела».
Вспоминаем самое главное правило: job story существует в мире потребителя, в своем мире потребитель находится в какой-то ситуации, хочет эту ситуацию как-то изменить, чтобы получить какой-то результат. Вашего (или любого другого) продукта в мире потребителя нет.
«Когда я голодный, я хочу быстро и вкусно поесть, чтобы не думать о еде».
Чем больше информации о ситуации и желаемом результате, тем лучше мы понимаем потребителя. В ситуации главное не уйти в незначительные детали. А в результате — задавайте вопрос «Чтобы что?».
«Когда я еду за рулем, я хочу быстро поесть, чтобы не отвлекаться и успеть доделать все дела».
В ситуации «когда я еду за рулем» нет и намека на проблему или хотя бы затруднение — ну едет человек и едет. Нет проблемы — человек не прилагает усилий для изменений, а значит, и не нужны решения — нет необходимости решать несуществующую проблему.
Ищем «большую работу» для потребительского сегмента
Job stories, описанные выше, достаточно детальны. Такой формат можно использовать для разработки продуктовых фич или сообщений о ценности продукта для конкретных контекстов. Назовем их «маленькими работами».
Но если мы работаем над ценностным предложением продукта, чаще наша задача — найти «большую работу». Для этого надо подняться над контекстом и так его обобщить, чтобы не потерять ценную конкретику, но и не уйти в незначительные детали.
Предположим, в нашем случае потребительский сегмент — «люди, которые следят за своим питанием». Что для них важно?
В процессе исследования или в результате формулировки гипотез мы узнали или определили, что в контексте питания такие люди следят за составом продуктов, стараются избегать вредного (сахара, мучного и т. д.) и, конечно, понимают: если хочешь есть — надо есть, а не искать таблетки от голода.
Для этого потребительского сегмента мы можем сформулировать «большую» job story следующим образом:
Комментарии:
Отлично, если результат говорит об эмоциях человека, а не решении функциональной задачи. Тогда, скорее всего, нам удалось нащупать именно «большую работу».
Как использовать job story
Вариантов использования job story много, но все они крутятся около двух задач:
В итоге все это делается для разработки продуктов и коммуникации его ценности.
Как Job Stories помогут в создании крутого интерфейса?
Несколько лет назад между разработчиками и пользователями было очень большое расстояние. Компании использовали моделирование персон и создавали пользовательские истории перед разработкой продукта. Сегодня этой связкой никого не удивишь, и с каждым годом она становится менее эффективной.
Составлением user stories занимаются маркетологи, биздевы или продажники. Они собирают информацию о целевой аудитории, упаковывают и передают разработчикам, чтобы у тех в работе были ориентиры.
Это неплохой подход, используемый много лет, но он имеет существенный недостаток: при передаче данных теряется множество важных нюансов. Разработчики не знают, почему пользователи ведут себя так, как ведут, чем они интересуются и что их мотивирует на совершение тех или иных действий.
Разработчик поймет своего пользователя тогда, когда научится распознавать его эмоции и откликаться на них.
Для создания успешного продукта разработчики должны понимать, что определяет поведение человека, какие у него есть проблемы и мотивация. Для создания удобного интерфейса (хотя этот метод не ограничен одним направлением деятельности) используют Job Stories, о которых мы и поговорим в этой статье.
Создание персон все еще популярно в разработке новых продуктов. Маркетолог придумывает вымышленного персонажа и считает, что именно он будет использовать приложение (сервис, товар, услугу и т.п.). На первый взгляд кажется, что это хороший ориентир для разработки, если бы не одно «но». Эта персона вымышленная.
Поможет ли обобщенное описание потенциального клиента (пол, возраст, цвет кожи, любимый досуг и т.п.) понять, почему сегодня куплен букет роз в одном из магазинов? Но если будем знать, что у жены клиента сегодня день рождения, становится понятна мотивация покупки.
Сразу рассмотрим простенький пример пользовательской истории: настроив автоматическое удаление старых заметок, я могу отметить важные, чтобы сохранить их для дальнейшего использования. Есть три проблемы:
Работая с пользовательскими историями, разработчики сталкиваются с низкой эффективностью UX. И понять причину сложно, поэтому рассматривают все возможные варианты: ошибка в реализации, неправильное предположение мотивов и т.п.
Персоны не работают, пользовательские истории тоже. Что же делать? Пришло время поговорить о Job Story — новом слове в проектировании и разработке пользовательских интерфейсов.
Job Story — это метод работы над продуктовыми фичами, их UX и UI. В основе лежит решение разных задач пользователей: скоротать время ожидания, получить доступ к нужному контенту и т.д. Метод впервые описал Пол Адамс. Позже он подробнее раскрыл свои мысли.
Посмотрите на схему выше и увидите разницу с пользовательскими историями. Здесь не рассматривается конкретный персонаж. Упор делается на определенные ситуации. Например, кто-то использует приложение, когда стоит в очереди в магазине, чтобы скоротать время ожидания.
То есть User Story описывают функциональность продукта с точки зрения пользователя, а Job Story — выявляют одинаковые мотивы поведения разных людей в конкретных ситуациях.
Если хорошо поработать с Job Story и получить много сценариев, можно:
Job Story дает продукту больше пользы, но все равно не пользуется большой популярностью среди российских продакт-менеджеров. Начните сегодня использовать этот метод в работе и завтра обойдете многих конкурентов.
С теорией все просто, поэтому перейдем к практике. Посмотрите алгоритм использования Job Story в работе:
Кроме проработки Job Story, проводите небольшое JTBD-исследование (Jobs To Be Done — концепция, к которой относится Job Story). Вы копнете глубже, посмотрите на продукт с разных сторон и узнаете его по-настоящему. Для проведения исследования ответьте на несколько вопросов:
Соберитесь всей командой или хотя бы ключевым составом и потратьте несколько часов на разбор вопросов. Полученные коллективным мышлением ответы удивят вас и вполне вероятно, что появятся новые и интересные решения, способные вывести продукт на новый уровень.
Рассмотрим конкретный пример использования метода. Допустим, у нас есть сервис для финансовых консультаций. Одна из услуг — подбор кредита для клиентов, расчет стоимости и подача заявки сразу в несколько банков. Нужно разработать профиль сотрудника, работающего в компании.
Обратите внимание, мы рассмотрим пример с одной историей. В реальности разрабатывают несколько вариантов и рассматривают каждый по отдельности.
В этом проекте высокоуровневая задача — создать удобный инструмент по подбору кредитов. Обычно клиенты готовят большой пакет документов, что занимает много времени. Постараемся исправить это.
Оформляя кредит, человек предоставляет много информации: цель кредитования, доходы, место проживания, имущество и т.п. Это ценные данные и каждый хочет быть уверен, что они будут надежно защищены и не попадут в руки третьих лиц.
Решают задачу старым способом: смотрят в интернете сайты банков, изучают условия. Потом идут в несколько отделений, заполняют первичные заявления (на это уходит несколько часов). Когда получают предварительные одобрения, выбирают банк, с которым хотят сотрудничать (по личным критериям выбора).
Описываем одну или несколько Job Story, уделяя внимание причинам, страхам и стимулам потребителя:
Это один пример, в реальности для этой ситуации можно придумать много различных ситуаций. Чтобы улучшить историю, добавляйте детали и уточняйте контекст. Например, человек может оформлять кредит в едином интерфейсе как из дома, так и из офиса, то есть привязки к какому-то конкретному месту нет. Проработайте все сложности, создавая профиль и работая с ним.
Подумайте, что можно сделать для разрешения истории желаемым образом. Обычно помогает изменение интерфейса или добавление новой фичи. Кстати, не забывайте проверять нововведения на соответствие Feature/Product Fit.
На основе истории составляется перечень функций и информации, которые должны быть в профиле сотрудника компании. Важно определить точный набор нововведений. Ведь если их будет больше или меньше, поставленную задачу решить не получится.
На основе примера можно сделать несколько выводов:
На основе этих выводов делаем новый интерфейс или вносим правки в уже существующий. Далее отслеживаем, как пользователи взаимодействуют с продуктом, с какими проблемами сталкиваются и т.п. и вносим правки, чтобы приложение соответствовало product market fit.
Намереваясь создать какой-то продукт, вы должны понимать, как люди решают свои проблемы в жизни. Когда им приходится это делать, по каким причинам и что их стимулирует? Ответы на эти, казалось бы, несложные вопросы дают много ценной информации.
User Stories теряют популярность, ведь они дают только общие черты потенциальных потребителей и отвлекают разработчиков от действительно важных вещей. Чтобы продукт был действительно эффективным и полезным, надо изучить, как он будет решать задачи пользователей. Методика Job Story помогает понять, какие функции добавить в продукт, чтобы удовлетворить потребность клиента, и какой UX принесет наибольшую пользу.
