Персонажи + Jobs-to-Be-Done: опыт применения объединенного подхода
При планировании развития продуктов часто используют либо фреймворк персонажей, либо Jobs-to-Be-Done (JTBD). В нашей практике бывают проекты, в которых требуется совместить эти подходы. В статье мы расскажем о нашем опыте их объединения.
Недавно мы тестировали мобильное приложение сервиса для поиска работы. Клиент хотел определиться с планом развития продукта и добиться максимальной продуктивности команды разработки. Для этого нужно было одновременно решить три задачи:
- выявить потребности и модели поведения разных групп пользователей при работе с приложением;
- провести анализ прямых и непрямых конкурентов, выявить наиболее частые потребности пользователей и разработать уникальное торговое предложение;
- в наглядной форме донести полученную информацию до членов команды, чтобы все работали на достижение общей цели и говорили на одном языке.
Для решения первой задачи мы создали несколько персонажей, которые отражают потребности различных групп пользователей и вокруг которых можно построить весь процесс разработки продукта (не более 3–4 персонажей, чтобы разработчики могли легко их запомнить и постоянно держать в уме). Для детального выявления потребностей и определения круга непрямых конкурентов мы применяли фреймворк Jobs-to-Be-Done. Полученную информацию мы представили команде клиента в виде Карты пользовательского опыта.
В этой статье мы на упрощенном примере покажем, как можно применять объединенный подход. Надеемся, что эта информация поможет вам лучше узнать потребности пользователей и создать востребованный продукт.
Почему одного фреймворка недостаточно?
Фреймворк Jobs-to-Be-Done основывается на том, что у пользователя есть определенная задача («работа»), которую ему надо выполнить, и он «нанимает» продукт, который наилучшим образом поможет ему в этом. JTBD, как и фреймворк персонажей, применяется для определения потребностей пользователя и наиболее востребованных свойств продукта, но рассматривает не индивидуальные особенности человека, а обстоятельства, от которых зависит решение человека «нанять на работу» тот или иной продукт.
По мнению сторонников JTBD, фреймворк персонажей фокусируется только на индивидуальных особенностях пользователя, это делает картину пользовательского пути негибкой и добавляет массу деталей, лишь косвенно влияющих на пользовательский опыт. Приверженцы фреймворка персонажей утверждают, что JTBD опирается исключительно на ситуации решения проблем пользователей, поэтому он упускает из виду реальных людей, что приводит к созданию слишком сухого и слишком функционального пользовательского опыта.
Чтобы использовать сильные стороны этих подходов и сгладить их недостатки, предпринимались различные попытки их объединения.
Основания для объединения подходов
Фреймворк Jobs-to-Be-Done описывает потребности пользователя по формуле: когда X, я хочу Y, чтобы Z. Первое место в этой формуле занимает ситуация (Х): «Когда я не знаю, как добраться до места (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z). Предполагается, что в такой ситуации может оказаться каждый, поэтому человек как переменная не включен в формулу. Таков принцип JTBD: важнее понять, как именно люди решают проблему и какие у них есть потребности в разных обстоятельствах, чем учитывать, что это за люди.
Фреймворк персонажей тоже может быть описан по формуле, но в ней первое место (Х) займет персонаж: как Х, я хочу Y, чтобы Z: «Как турист (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z)».
Если представить эти подхода таким образом, идея совместить их становится очевидной. Мы не первые, кто объединил эти подходы. Даже представители школы Алана Купера, который и предложил использовать персонажей в качестве методологии разработки интерфейсов, признают потенциальную полезность такого скрещивания.
Пейдж Лаубхеймер (Page Laubheimer) из NNGroup также не видит существенных противоречий между этими подходами, хотя и акцентирует внимание на том, что персонажи должны быть правильно описаны с точки зрения релевантности их ключевых черт продукту. Если персонажи рассказывают о том, кто такие пользователи продукта, то «работы» сообщают о ключевых целях этих пользователей.
Клэр Менке (Claire Menke) из Udemy предлагает объединить JTBD и персонажей на основе иерархии: «Установки влияют на вероятность возникновения тех или иных ситуаций, а ситуации влияют на конкретный опыт». Таким образом, на верхнем уровне находятся персонажи — основные типы пользователей, затем — «работы» (задачи персонажей в рамках определенных обстоятельств), а в основании — конкретные переживания пользователя на разных этапах пути.
Возможны разные варианты совместного использования этих подходов, и то, как конкретно они будут объединены, зависит в первую очередь от задач команды продукта.
Наш опыт применения объединенного подхода
Допустим, клиент хочет сделать редизайн приложения-будильника. Чтобы создать востребованный продукт, ему нужно понять, какие потребности есть у людей, когда они встают по утрам.
Здесь ключевая «работа» (Сore Job) — проснуться и встать вовремя, и нам нужно понять, как люди решают эту задачу и в какой контекст она встроена. Используя JTBD, мы не должны фиксироваться ни на конкретном решении, например, на мобильном приложении «Будильник», ни на будильнике как типе продукта вообще. Нам нужно собрать все возможные решения задачи, например: попросить другого человека разбудить меня, запрограммировать телефонный звонок, лечь спать заранее, чтобы проснуться самостоятельно, использовать умные часы, которые учитывают биологические ритмы и сами подбирают оптимальный момент для пробуждения, и т. п.
Одновременно нам надо понять, есть ли различия между потенциальными пользователями будильника на уровне потребностей. Для этого мы должны:
- выяснить, почему тот или иной человек «нанимает» определенный продукт для решения своей задачи (какие имплицитные, то есть не выраженные в явном виде, потребности лежат за каждым из его решений);
- определить критерии, выполнение которых будет свидетельствовать о том, что потребность удовлетворена.
Всю необходимую для этого информацию мы собираем в процессе интервью:
- выделяем типы пользователей, работающих с продуктом, и на их основе создаем персонажей;
- для каждого персонажа составляем Карту пользовательского опыта, которая описывает процессы, приводящие его к пониманию, что нужно использовать будильник;
- на каждом этапе Карты пользовательского опыта описываем «подработы», которые необходимо выполнить пользователю для выполнения ключевой «работы».
Такой подход позволяет нам добавить временное измерение в описание процесса принятия персонажем решения использовать будильник и учесть информацию о том, как пользователи в принципе выбирают продукты.
Подготовка к интервью
Несмотря на то, что все мы по утрам так или иначе выполняем «работу» встать вовремя, подготовка к интервью по объединенной методике является сложным и комплексным процессом. На этапе разработки сценария интервью нам необходимо учесть 3 аспекта:
- ключевые особенности пользователей или сегментов пользователей (будущие персонажи);
- контекст «найма на работу»;
- состав «работ», для которых потенциальные пользователи могут «нанять» наш продукт.
Проводим первичную сегментацию
До интервью нам необходимо сформировать гипотезы о том, какие индивидуальные особенности могут повлиять на опыт выполнения «работы» встать вовремя. Такие свойства можно представить в виде шкалы, на которой в итоге мы сможем расположить персонажей, согласно полученным данным.
Например, это могут быть следующие свойства:
- чувствительность к звуку (легко или сложно расслышать будильник);
- важность задачи встать вовремя (свободный или строгий график);
- соседство с другими в спальне (партнер, дети, студенческое общежитие).
Размышление о таких критериях распределения персонажей на шкалах свойств уже на этапе предварительного анализа позволяет выдвинуть гипотезу о персонажах, которую потом непременно нужно будет проверить на реальных данных:
Персонаж № 1 — человек с плохим слухом, которого штрафуют за опоздания.
Персонаж № 2 — человек с хорошим слухом, у которого свободный график, можно приходить на работу поздно.
Персонаж № 3 — пара: у партнеров разные графики и они стараются не разбудить друг друга.
Важно, что персонажей мы с самого начала не наделяем никакими социально-демографическими характеристиками (пол, возраст, доход и пр.), потому что нам необходимо сфокусироваться на их общем жизненном стиле и способах мышления. Подробнее о том, как избежать стереотипов при создании персонажей, можно прочесть в статье Инди Янг (Indi Young) Describing Personas.
В процессе интервью нам надо будет задать вопросы, которые позволят описать каждого участника интервью с точки зрения выделенных свойств. Поэтому важно заранее составить максимально широкий список свойств, которые могут иметь значение. Лучше после интервью вычеркнуть незначительное, чем на десятом интервью понять, что есть еще одно важное свойство персонажа, о котором вы не спросили 9 предыдущих респондентов.
Учитываем контекст
Чтобы охватить наиболее широкий контекст вокруг ключевой «работы», необходимо задать участнику интервью общие вопросы. Как он проводит день? Как устроена его неделя? Какой у него жизненный график? Как он в целом обращается со временем? Какие устройства он использует в контексте контроля времени и в контексте пробуждения (это могут быть два разных контекста, вытекающих из двух слов, составляющих ключевую «работу»: «проснуться» и «вовремя»)?
Кроме того, чтобы узнать, какие средства выполнения «работы» пользователь применяет уже сейчас, необходимо уточнить, как он пришел к тому, чтобы использовать эти средства. Например, сейчас он использует умные часы, позволяющие проснуться свежим и отдохнувшим за счет отслеживания цикла сна. Как именно он к этому пришел? В какой момент? Какую проблему пытался решить? Какие альтернативы рассматривал?
Детализируем «работу»
Далее мы формулируем примерные гипотезы о «подработах» — составных частях ключевой «работы». «Подработы» могут выполняться в любом порядке, но могут и составлять естественную или типичную последовательность этапов. Авторы концепции JTBD предлагают универсальные этапы, которые помогают сформулировать «подработы» почти для любой «работы»:
В нашем случае с будильником примерные этапы («подработы») могут быть такими:
Подготовка ко сну -> Планирование подъема утром -> Заснуть -> Сон -> Пробуждение -> Подъем.
Сформировать понимание возможных этапов («подработ») важно еще на этапе подготовки к интервью, однако называть эти этапы в процессе интервью не стоит. Вместо этого надо фокусироваться на структурных шагах и формулировках пользователя и начать интервью с самого общего вопроса: «Когда мы говорим о том, что вам надо встать вовремя, что приходит вам в голову?»
Прощупывая естественные этапы каждого участника интервью, обязательно добавляем вопросы про ключевые потребности и цели на каждом этапе. Они могут быть такими:
· Что является самым важным на данном этапе?
· Что занимает больше всего времени/доставляет больше всего неудобств? Какие сейчас есть способы справляться с неудобствами?
· Кто еще участвует в «работе» на данном этапе? Каким образом (например, советует, помогает принять решение, протестует и пр.)?
· Что мешает и что помогает в достижении цели (потенциальные барьеры и драйверы)?
Эти вопросы полезно иметь в голове в качестве проверочных, чтобы выявить суть потребностей пользователя, но в процессе интервью формулировать их, скорее всего, надо по-другому, адаптируя к контексту беседы.
Схема интервью
Зону интереса, изучаемую в ходе интервью, предварительно можно графически обозначить примерно так:
Синяя зона — это общий контекст деятельности пользователя; красные блоки — составляющие ключевой «работы», основной фокус интереса; оранжевые блоки — контекст и истории вокруг каждого этапа (были ли другие решения? почему они не сработали? есть ли какие-то решения, которые пользователь еще не попробовал, но планирует? почему все еще не попробовал, что его останавливает?).
В процессе интервью
Стоит подготовиться к тому, что интервью будет долгим. Надо иметь в запасе не меньше часа, а лучше полтора часа, чтобы коснуться всех важных аспектов.
Общая установка в процессе интервью — собрать как можно больше контекста, задавать вопросы на расширение/углубление контекста, но фокусироваться именно на том, почему человек совершает те или иные действия.
Например, респондент мимоходом отмечает, что открывает перед сном форточку. Стоит спросить: «Зачем?» Может выясниться, что он плохо спит в духоте, поэтому нуждается в свежем воздухе, однако под окном у него шоссе, поэтому ближе к утру он обычно просыпается от звука машин, — а это уже что-то, что имеет непосредственное отношение к пробуждению.
Респонденту стоит сообщить, что вы заинтересованы в максимально подробных ответах. Одна из техник — предложить представить, что вы снимаете документальное кино, историю об опыте респондента и вам важно получить информацию о деталях: обстановке, действиях, переживаниях и т. п. Подробнее о том, как брать JTBD-интервью и на что обращать внимание в процессе интервью, можно узнать в этом подкасте.
Анализ результатов и составление Карты пользовательского опыта
Предположим, в ходе интервью мы выделили персонажей, которых описали выше, и подтвердили гипотезу о трех базовых шкалах свойств:
· чувствительность к звуку (низкая/высокая);
· график (строгий/свободный);
· риск разбудить других (низкий/высокий).
Наши персонажи расположились на этих шкалах свойств следующим образом:
Теперь мы можем конкретизировать ключевую «работу» встать вовремя для каждого персонажа, чтобы отразить, что в первую очередь он ищет, выбирая способ для достижения этой цели.
Например:
· Персонаж 1 «Плохой слух + штрафы в офисе» –> «Работа»: встать вовремя, не опоздать в офис;
· Персонаж 2 «Хороший слух + расслабленный график» –> «Работа»: встать вовремя, проснувшись легко, с хорошим настроением;
· Персонаж 3 «Пара: разные графики» –> «Работа»: встать вовремя так, чтобы не разбудить партнера.
Таким образом, ключевая «работа» обрастает нюансами в зависимости от специфики персонажей и их стиля жизни.
Затем определяемся со слоями опыта. В нашем случае мы взяли следующие слои:
· Цели/Потребности — к чему стремится персонаж;
· Опасения — наихудший вариант развития событий;
· Действия — что делает персонаж, чтобы достичь цели;
· Барьеры — что мешает достичь цели;
· Инструменты — что помогает достичь цели;
· Эмоции.
Как выглядит результат
Результатом исследования становится Карта пользовательского опыта, описывающая поведение персонажа в рамках интересующего нас аспекта жизни пользователя в целом.
Карта должна отображать не только суть «работы», но и суть персонажа: его название и его персональную формулировку «работы» (задачу), а также контекст, в котором возникает задача, и специфику потребностей на каждом из этапов «работы».
Столбцы в этом примере Карты пользовательского опыта для приложения-будильника на первый взгляд выглядят линейно, но здесь необязательно есть строгая временная последовательность. Этапы могут меняться местами: персонаж может при определенных обстоятельствах в буквальном смысле слова «отрубиться» после изнурительного рабочего дня и начать JTBD с этапа «Сон», но проснуться среди ночи (этап «Пробуждение»), подготовить вещи к подъему (этап «Подготовка ко сну»), снова начать засыпать (этап «Заснуть») и только потом вспомнить про будильник (этап «Планирование подъема»).
Подобная Карта является эффективным инструментом для выявления инсайтов относительно проектируемого продукта, потому что она позволяет зафиксировать контекст — действия, тревоги, переживания и привычные практики персонажа, а также его ключевые потребности, проблемы и способы их решения.
В чем преимущество комбинации подходов JTBD и персонажей при картировании пользовательского опыта
Создавая Карту пользовательского опыта с применением объединенного подхода, мы одновременно получаем новый инструмент для формулировки инсайтов и подсказку для расстановки приоритетов в списке доработок продукта.
Сочетание персонажей и Jobs-to-Be-Done позволяет достичь компромисса в персонификации целевой аудитории. Поскольку JTBD рассматривает не индивидуальные особенности человека, а ситуации, от которых зависит его решение «нанять на работу» тот или иной продукт, то при использовании объединенного подхода увеличивается степень анонимизации пользователя. Мы переходим от описания конкретной личности с ее особенностями к описанию абстрактной массы людей, отказываясь от сегментации аудитории в привычном смысле за счет смещения акцента с частных деталей на общие паттерны поведения.
Драйверы, барьеры и триггеры, выявленные благодаря применению объединенного подхода, не привязаны к определенному индивиду с учетом его демографических и поведенческих особенностей, но тем не менее характерны для конкретной группы пользователей. Это позволяет не только снизить искажение, свойственное персонажу, но и «оживить» инсайты JTBD. Благодаря таким экспериментам Карта пользовательского опыта становится более универсальной и в то же время помогает избавиться от стереотипных дизайн-решений, которые не имеют достаточного основания по результатам проведенных исследований.
