Фреймворк Jobs to Be Done часто противопоставляют Personas — «методу персон», который подразумевает создание портрета представителя целевой аудитории. В этом материале мы разберемся, почему каждый из этих методов по-своему хорош для работы над определением целевой аудитории и затачиванием продукта под ее потребности.
Эта статья была в 2017 году Page Laubheimer, Senior UX Specialist в блоге Nielsen Norman Group. Мы предлагаем вам прочитать ее адаптированный перевод.
Развивайтесь в профессии продакт-менеджера с помощью GoPractice.
→ «Профессия: продакт-менеджер».
→ «Симулятор управления продуктом на основе данных».
→ «Симулятор управления ростом продукта».
→ «Симулятор SQL для продуктовой аналитики»
→ «Симулятор управления ML/AI-проектами».
→ «Генеративный AI для продакт-менеджеров: мини-симулятор».
→ Не знаете с чего начать? Пройдите бесплатный тест для оценки навыков управления продуктом и подпишитесь на телеграм-канал .
Введение
«Метод персон» (Personas) давно зарекомендовал себя как полезный инструмент в работе над созданием и затачиванием продуктов под конкретные типы пользователей. Однако в последние годы все более популярным становится подход Jobs to Be Done, который фокусируется на потребностях пользователей.
Jobs to Be Done (JTBD) — это фреймворк, в основе которого лежит идея, что пользователи «нанимают» продукты для выполнения определенной «работы». Набор «работ» для продукта представляет собой полный список потребностей пользователя.
С ростом популярности JTBD все чаще звучат призывы отказаться от «метода персон» под предлогом того, что JTBD — гораздо более полезная техника. Но эта точка зрения основана на ошибочном представлении о том, что «метод персон» — это лишь набор преимущественно демографических характеристик пользователей. Такой неверный взгляд на «метод персон» упускает из вида ключевые поведенческие характеристики, которые критично важны для создания хорошей «персоны» и дают гораздо более глубокое понимание того, как выстраивать и затачивать продукт.
Jobs to Be Done: полезный инструмент для фокуса на результатах, которых хотят добиться пользователи
Фреймворк Jobs to Be Done позволяет определить потребности пользователей через качественные исследования, например, JTBD-интервью. Вы узнаете, для достижения каких целей пользователи «нанимают» ваш продукт. А в идеале еще и выясните, готовы ли пользователи «уволить» продукты конкурентов и какие именно.
На основе этого понимания продуктовая команда может по-новому взглянуть на основные проблемы и потребности пользователей, а затем — заточить продукт таким образом (например, разрабатывая нужные фичи), чтобы он смог закрывать эти потребности как можно более эффективно.
Хотя фреймворк JTBD является относительно новым, многое роднит его с уже устоявшимися методами, например анализом задач (task analysis) и анализом юзкейсов (use cases), которые учитывают контекст, цели и этапы взаимодействия с продуктом. Вот в чем различия:
- Анализ задач и анализ юзкейсов помогают понять, как наилучшим образом продукт может «вести себя» в работе с типичными активностями пользователей. Часто эти методы склоняют вас к поиску решения в рамках уже существующих подходов.
- Подход JTBD смещает акцент с самого процесса типичных активностей на конкретные результаты, которых пользователь хочет достичь, а также помогает задаться вопросом, являются ли эти типичные активности наилучшим способом достижения того результата, который пользователям в действительности нужен.
JTBD в меньшей степени предписывает, в чем именно заключается задача пользователей и как именно они будут ее выполнять.
Давайте обсудим на примере.
Допустим, традиционный анализ задач помог выяснить, что водителям сервисов доставки часто требуется распечатывать маршруты для их остановок. В таком случае продуктовая команда сфокусируется на том, чтобы облегчить для водителей подготовку и печать этих маршрутов.
Однако JTBD поможет сосредоточиться на «работе», которую хотят делегировать водители доставки, а именно — на более легкой навигации во время движения. И тогда команда будет искать решения этой проблемы в другой плоскости, например, через внедрение GPS-навигации с голосовыми указаниями.
JTBD подразумевает, что инновации и действительно хороший дизайн — это результат оценки реальных потребностей клиентов и создание такого решения, которое не ограничено рамками существующих подходов и продуктов. Впрочем, иногда радикальные инновации могут быть дорогостоящей и рискованной стратегией улучшения продукта.
Сторонники JTBD часто вспоминают цитату профессора Гарвардской школы бизнеса Теодора Левитта (Theodore Levitt): «Люди не хотят покупать сверло для дрели в четверть дюйма. То, что они хотят — это отверстие диаметром в четверть дюйма». Вместо фокуса на наборе продуктовых фичей фреймворк JTBD заставляет команду думать о результатах:
- Смогут ли пользователи легко и с удовольствием выполнить «работу», для которой они «наняли» продукт?
- Дает ли конкретное решение лучший результат в сравнении с альтернативами?
Чаще всего «работу» определяют в одном предложении, где указано:
- Что именно пользователь хочет сделать;
- В каком контексте (где или когда или зачем).
Описание конкретной «работы» обычно предусматривает следующий уровень детализации:
- Функциональные критерии успеха — объективные и прозрачные требования для успешного выполнения «работы»;
- Эмоциональные критерии успеха. Они могут быть декомпозированы на персональные эмоциональные критерии и социальные эмоциональные критерии.
«Метод персон» выходит за рамки демографических данных
Многие аргументы в поддержку того, что «персоны» потеряли актуальность с появлением фреймворка JTBD, ошибочны в том, что «персоны» рассматриваются как преимущественно демографические характеристики клиентов.
Действительно, демографические данные неудобны для принятия продуктовых решений, поскольку ничего не говорят о поведении пользователей и их отношении к чему-либо. Такая информация в основном подходит для принятия маркетинговых и рекламных решений.
Но на самом деле, «персоны» задуманы как достаточно обширное представление о пользователях и должны включать куда больше информации, чем демографические или типовые анкетные данные. Большинство хорошо составленных «персон» включают в себя большое количество информации, в том числе:
- Демографическую информацию, включая возраст, семейное положение и уровень дохода;
- Персональную информацию, включая короткую биографию, фотографию, имя;
- То, как пользователь к чему-либо относится и как воспринимает. Например, информацию о «персоны», и ;
- Цели и мотивы для использования продукта;
- Поведенческие данные о том, как «персона» обычно ведет себя при использовании продукта.
Демографическая и личная информация необходима по двум причинам:
- Чтобы выстроить эмпатию продуктовой команды к «персоне»;
- Чтобы мнемоническим путем сделать этот портрет «персоны» запоминающимся для команды.
К сожалению, зачастую портреты «персон» ограничиваются лишь демографической и личной информацией, из-за чего на фоне JTBD они перестают быть полезными при принятии продуктовых решений. По факту, они становятся ничем иным, как маркетинговыми сегментами.
Качественно выстроенные «персоны» во многом опираются на поведенческие данные, информацию о персональных предпочтениях людей и ментальные модели. Для этого требуются качественные исследования с реальными пользователями — это дает ответ на вопрос «почему?», скрытый за поведением пользователей. Эти обогащенные «персоны» чаще всего содержат информацию о конкретных целях, которых пользователи хотят достичь при использовании продукта. И эти цели напрямую сопоставимы с тем определением, которое мы даем фреймворку Jobs to Be Done.
Jobs to Be Done не формирует эмпатию
Ключевая причина, по которой «метод персон» сфокусирован на реалистичных портретах пользователей, заключается в необходимости уйти от анкетного подхода, где нужно просто проставить галочки различным характеристикам и требованиям. Вместо этого «метод персон» предлагает сфокусироваться на том, каким именно должен быть пользовательский опыт.
И хотя JTBD в некоторой степени учитывает эмоциональный и социальный контекст пользовательской задачи, обычно все эти данные обобщены для пользовательской базы целиком, либо достаточно широкого сегмента. Таким образом, сформировать эмпатию к конкретному пользователю у продуктовой команды не удается.
«Метод персон» помогает с приоритизацией среди различных групп пользователей
Представьте следующий сценарий: ваша команда делает новую версию популярного десктопного приложения для продуктивности.
В последние годы на рынок пришли конкуренты с инновационными продуктами, и руководство вашей компании хочет провести редизайн, чтобы оставаться конкурентоспособными на рынке.
Несмотря на то, что JTBD-интервью с текущими и потенциальными пользователями об их «работах» будет полезным, важно осознавать и различия между этими группами.
- Если вы разрабатываете дизайн с нуля с прицелом на новых пользователей и их «работы», с большой вероятностью вы сильно измените флоу для ваших текущих пользователей, тем самым сильно навредив их продуктивности (им придется заново учиться пользоваться вашим продуктом).
- Если вы сделаете полный редизайн старой фичи (или, как это часто предписывает JTBD, найдете абсолютно новое решение задачи пользователей), вы опять же можете навредить вашим существующим пользователям.
В работе над пользовательским опытом, продуктовые команды должны постоянно балансировать между интересами различных групп пользователей, которые подчас противоречат друг другу.
У всех покупателей дрели схожая «работа» — сделать отверстие. Тем не менее профессиональному подрядчику будет в первую очередь важна надежность инструмента, а тому, кто хочет повесить несколько картин в доме, будет важнее его стоимость. Эти два фактора конфликтуют между собой, поэтому если мы будем фокусироваться только на «работе» без учета различий в группах пользователей, мы, скорее всего, придем к неудовлетворительному решению, каким бы инновационным оно ни было.
Хотя у разных пользователей будут разные требования к выполнению одной и той же «работы», обратная ситуация тоже случается: одна группа пользователей (или «персона») может «нанимать» продукт для совершенно разных «работ» в разных контекстах.
Например, вы пользуетесь одним и тем же сайтом для покупки авиабилетов и в командировку, и в отпуск. Эти типы поездок подразумевают совершенно разные «работы», но каким бы ни был контекст вашего обращения к сайту, у вас всегда одна и та же ментальная модель и поведенческие характеристики — летите ли вы на конференцию продакт-менеджеров в Лиссабон или в семейное путешествие в Таиланд.
Вероятнее всего, ваши поведенческие характеристики и некоторых других пользователей похожи, а с некоторыми у вас мало чего общего. Именно поэтому нужно создавать несколько «персон». Это необходимо, чтобы отразить ключевые дифференциаторы между группами пользователей, а затем научиться балансировать между ними и приоритизировать.
«Метод персон» и фреймворк JTBD совместимы
Несмотря на множество противоречивых мнений о том, что JTBD заменит «метод персон», оба подхода на самом деле совместимы. В зависимости от потребностей вашей организации и от того, опирается ли ваша команда на «персон» или JTBD, их можно задействовать вместе.
- В организациях, опирающихся на JTBD, выявленные «работы» можно дополнить информацией об уникальных дифференциаторах на основе функциональных или эмоциональных критериев успеха для «персон».
- Если ваша организация уже опирается на «метод персон», но эти портреты не содержат целей или поведенческих характеристик (критично необходимых для эффективной работы «метода персон»), начните дополнять «персоны» через призму JTBD. Вместо того, чтобы просто перечислить цели и задачи персоны, попробуйте преобразить эту информацию в «работы» и задайте себе вопросы о том, чего хочет достичь этот пользователь и какие критерии успеха для него важны.
- Если ваша организация противится «методу персон» (например, потому что не получилось убедить топ-менеджмент или коллеги настроены слишком скептично), но при этом в ней есть острое желание использовать данные о пользователях для улучшения продукта, JTBD будет полезной альтернативой. Вокруг фреймворка JTBD много позитивных откликов в бизнес-литературе, и это может способствовать энтузиазму для его внедрения. Впоследствии вы сможете совместить JTBD с «методом персон», заручившись поддержкой руководства и коллег.
Заключение
Удобство использования любого продукта можно оценить только в отношении к двум переменным: кто пользователи и что они хотят сделать. Поэтому, чтобы юзабилити-исследования продукта приносили пользу, важно набирать релевантных тестовых пользователей и давать им релевантные задачи.
Один дизайн продукта может быть хорош для одной категории пользователей и совершенно непонятен для другой группы. Если вы будете проводить исследование на неподходящей выборке, вы ничего не узнаете о реальных юзкейсах.
Именно поэтому вы должны строго определять целевых пользователей и их задачи во время работы над продуктом. В противном случае вы рискуете создать продукт для неподходящей аудитории или с набором ненужных фичей. Для эффективной и успешной работы над пользовательским опытом вам понадобится ясно определить и конкретных пользователей, и их конкретные задачи.
«Персоны» — это не просто демографические или маркетинговые сегменты пользователей. Они включают в себя информацию и об их целях, потребностях, болях, ожиданиях. Вся эта информация упаковывается в нарративный формат, который формирует эмпатию у команды.
И хотя JTBD может быть полезным способом сформулировать конкретные «работы» пользователей, эта информация на самом деле уже представлена в хорошо проработанных «персонах».
Подробнее о Jobs to Be Done
- Перевод программной статьи Клейтона Кристенсена Know Your Customers’ “Jobs to Be Done” — о том, почему важно знать, какую именно задачу хотят решить ваши пользователи.
- Что такое Jobs to Be Done и как его применять: руководство от соавтора фреймворка Боба Моэсты
- Как подготовить и провести глубинное интервью. Гайд и шаблоны для JTBD-исследования
