Руководство по Jobs to be Done и Desired Outcomes для дизайна интерфейсов

Jobs to Be Done дает хорошую базу, но в полной мере не покрывает детали для проектирования интерфейсов. Расскажу, как я адаптировал подход для разработки цифровых продуктов, используя Desired Outcomes. С ними становится понятнее, что делать в продукте, они дают ответ на вопрос "чтобы что", и генерация идей перестает быть изнуряющим процессом.

Когда я начинал заниматься дизайном интерфейсов 9 лет назад, я искал подходы, которые позволят узнавать у пользователей, что им нужно, а не угадывать самому. Тогда я узнал про JTBD (Job To Be Done), но, как его применять в цифровых продуктах, мне было непонятно.

Job Stories в классической версии казались слишком общими и не давали достаточно конкретики, чтобы перейти от инсайтов к действию. Мне нужно было больше детализации, чтобы понять, что вообще нужно сделать в интерфейсе. Спасибо Джону Ульвику: в одной из его книг я нашёл термин Desired Outcomes. Тогда картинка сложилась. Desired Outcomes позволяли точнее определять, какие цели и подцели преследуют пользователи, решая свои задачи. Это дало основу, чтобы разбивать Job Stories на составные части и детализировать их до тех пор, пока на основе этого нельзя будет составить решения.

JTBD и Desired Outcomes чаще упоминаются в контексте маркетинга и физических продуктов, поэтому я адаптировал их комбинацию под свои задачи — для развития ПО.

Сейчас я внедряю этот подход в командах, с которыми работаю. Я опробовал на практике, как он помогает лучше понимать цели пользователей, декомпозировать их задачи и разрабатывать интерфейсы, которые делают жизнь аудитории проще и удобнее.

Делюсь руководством. В нём я расскажу про то, какую информацию собрать на исследованиях и как её проанализировать.

P.S. Статья подразумевает, что вы уже базово знакомы с подходом и понимаете его значимость. Если нужно раскрыть эту тему подробнее, напишите в комментариях.

В моём представлении весь продукт в контексте JTBD можно рассматривать в трёхступенчатой градации:

Три уровня градации

Верхний уровень — Core Functional Job, или основная задача, за решением которой пользователь приходит в продукт. Без определения этих границ будет сложно: если пытаться обслужить несколько равнозначных сценариев в первом запуске, то размоется ценность продукта и фокус при его разработке. Он нужен для запуска MVP и формирует у пользователей представление «что это такое».

Уровнем ниже идут Job Stories, которые создают дополнительную ценность, но без их обслуживания продукт вполне может существовать на начальных этапах. Создание решений для этих JS позволяет растить метрики, привлекать новую аудиторию и удерживать в продукте существующую.

Третий и самый детализированный уровень — Desired Outcomes. Это подзадачи, из которых состоит и Core Functional Job, и Job Stories. Конкретные решения или функции разрабатываются именно для DOs.

Поговорим подробнее о каждом из уровней.

Core Functional Job есть в любом продукте и содержит набор решений для определённой задачи в рамках MVP. Это нужно для того, чтобы аудитория понимала концепцию: о чём продукт и зачем он нужен.

CFJ проводит пользователя по ключевому сценарию, не давая каких-то дополнительных возможностей при самом первом релизе. После запуска продукт улучшается: мы находим Job Stories и придумываем для их обслуживания новые функции.

На примере продукта ВКонтакте, Core Functional Job включает базовые функции для социального взаимодействия: личный профиль, возможность написать сообщение и добавить человека в друзья.

В свою очередь, обмен аудио-сообщениями, прикрепление файлов в переписке, прослушивание музыки — это функции для развития. Без них продукт вполне может существовать на ранних этапах, но чтобы поддерживать интерес у пользователей, нужно чем-то их привлекать (например, ВКонтакте одним из первых анонсировал расшифровку голосовых сообщений). Каждая из таких функций обслуживает личную Job Story со своим набором Desired Outcomes.

Каждый продукт должен для себя определить самостоятельно, на решении какой потребности он хочет сосредоточиться в первую очередь для своего запуска. В большей степени, это зависит от его конкурентоспособности и наличия аналогов на рынке.

Для Домклик Core Functional Job строится вокруг сценария поиска недвижимости и оформления ипотеки, а для фитнес-браслета Xiaomi — вокруг отслеживания жизненно важных показателей.

Принципы

1. Core Functional Job описывает причину, по которой аудитория пользуется продуктом в целом.
2. Она постоянна, и её смена означает смену вектора развития продукта.
3. Core Functional Job может быть несколько, в зависимости от того, какие сегменты аудитории у вас есть. Например, в маркетплейсе недвижимости будут такие сегменты, как покупатели, арендаторы, собственники, риелторы и др. Для каждого из них — своя CFJ.

Как составить CFJ

Моя идея в том, что Core Functional Job описывается по принципу Job Story и содержит в себе Desired Outcomes. Сперва расскажу, как составляются последние два, а потом, для понимания, сложу пазл в общую картину.

Job Stories описывают конкретную задачу пользователя, и они нужны для развития продукта. Сформулировать их некорректно очень легко, а последствия от этого могут быть печальные. Слишком узкое определение JS ограничит возможности решений, а слишком широкое — размоет их границы.

Принципы

Главное — не воспринимать промежуточные действия пользователей как конечную задачу. При использовании электронных таблиц у людей нет цели «посчитать сумму через формулу в Excel». Вместо этого, у них есть цель «предоставить руководству отчёт с правильно посчитанными числами». В таком контексте формулы могут быть заменены на функцию автоматической генерации данных. Это решит задачу гораздо лучше.

Формируя Job Story, думайте о ней с позиции конечной задачи пользователя, а не того действия, которое они предпринимают для её выполнения.

Как составить JS

Учитываются три переменные:

1. Ситуация (Situation). Что делает пользователь, когда у него появляется задача для выполнения? В каком контексте он находится, какую должностную или бытовую обязанность выполняет?
2. Мотивация (Motivation). Что хочет сделать пользователь в контексте вышеописанной ситуации? Какие цели перед ним стоят?
3. Ожидаемый результат (Expected Outcome). Почему для пользователя важно достичь целей, описанных в предыдущем пункте? Что пользователь получит в итоге, чего добьётся или чего избежит?

В своей работе я делаю так:

1. Определяю на интервью задачу пользователей: что им необходимо сделать и почему это для них важно.
2. Определяю процесс решения задачи и количество действий.
3. Узнаю сложности на каждом из этапов.
4. Составляю Job Story и разбиваю их на Desired Outcomes (про них поговорим далее) для анализа причинно-следственных связей, тревог и мотивации пользователя.

Job Story задаёт направление, в котором команда должна двигаться. При разработке каждого решения мы можем спрашивать себя: приближает ли пользователя эта функция к тому, чтобы он решал свою Job Story проще, быстрее или дешевле?

Job Stories сами по себе хорошо доносят ценность продукта, но не раскрывают, как разработать сложные функции с множеством сценариев и деталей. Решается это с помощью Desired Outcomes. Это — подзадачи, которые пользователь решает при использовании какой-то функции или выполнении какого-то сценария. Для каждой Job Story их может быть несколько, и все решения для них в продукте направлены на повышение эффективности работы. Грубо говоря, цель решения — максимально сократить количество шагов и автоматизировать их для более быстрого выполнения задачи. По возможности, без вовлечения пользователя.

Например, когда регистрируешь почтовый ящик в Gmail, там есть поле для заполнения даты рождения. Практически везде в таких полях можно встретить иконку календаря. Если подумать над вопросом: «Зачем там эта иконка?», то можно услышать в ответ: «Так удобно». Но, на самом деле, там есть Desired Outcome:

В чём тут польза: можно сделать не только иконку календаря, но ещё и автоматически подтягивать дату рождения, скажем, из социальных сетей. Смещение акцента с решения на конкретную метрику позволяет нам придумать более полезные идеи. Благодаря такой оптимизации появилось решение, которое позволяет авторизовываться в сервисах через различные дополнительные аккаунты, а не заполнять множество полей при регистрации.

Когда вы сформируете у себя видение, что любая задача пользователя — это линейный процесс, у вас появится много пространства, чтобы его оптимизировать и улучшать. Вы научитесь видеть решения не только в рамках дизайна, но и за его пределами. Для меня это стало ключевым открытием во всей работе.

Каждая Desired Outcomes описывает выполнение задачи с использованием двух метрик:

1. минимизации времени на выполнение задачи;
2. минимизации вероятности негативного исхода.

Как составить DO

Учитываются две переменные:

1. Ситуация (Contextual Clarifier), в которой пользователь решает задачу.
2. Показатель эффективности (Performance Metric) — время или вероятность какого-то исхода.

Таких Desired Outcomes могут быть десятки для одной задачи, в зависимости от её сложности и масштабности. В своей работе я делаю так:

1. Определяю на интервью задачи пользователя: что им необходимо сделать и почему это для них важно. Уточняю этапы и количество действий. Формирую Job Story.
2. На основе данных из предыдущего шага разбиваю каждую Job Story на Desired Outcomes.
3. Накидываю с командой потенциальные решения для каждой из Desired Outcome: как этот процесс решения задач можно оптимизировать.

Если же интервью взять не получается, то можно посмотреть, как эту задачу решают конкуренты. Например, для платформы по проведению онлайн-мероприятий можно изучить как прямых конкурентов, так и косвенных (LMS-системы, стриминговые сервисы, обучающие платформы и пр.). Зачастую это упрощает работу. Многие функции уже сделаны и удивить рынок может быть нечем. К тому же, конкуренты могут вам подсказать, какие обязательные сценарии вы не учли, потому что «замылился глаз».

Покажу разницу между Job Stories и Core Functional Job на примере платформы для проведения онлайн-мероприятий.

При формировании CJF я не вдаюсь в мелкие подробности решения. Вместо этого я описываю его концепцию и ключевые возможности. Здесь же я отображаю основные процессы в жизненном пути пользователя — это позволяет посмотреть на картину целиком и понять, как их можно оптимизировать на глобальном уровне.

Дальше смотрю функциональность в разрезе этапов. Например, на втором этапе заведения события на платформе есть запрос от менеджеров на размещение проектов в черновиках. Это отдельная Job Story.

Если мы запускаем такую платформу, то возможность восстановить заполнение проекта — не первостепенная функциональность. Да, с ней продукт будет лучше, но и без неё он может существовать. У event-менеджера не возникнет вопроса: «А смогу ли я вообще воспользоваться платформой и завести проект?» Поэтому функцию черновиков я вывожу в отдельную Job Story, разбиваю её на Desired Outcomes и придумываю набор решений для обслуживания каждой из них. Ниже — пример DO:

Итог

Как видите, кардинальных отличий между Core Functional Job от Job Stories нет. Тем не менее, важно понимать иерархию.

Core Functional Job — MVP

Она формируется на этапе запуска и содержит в себе набор Desired Outcomes, без которых продукт не может существовать. Этот набор проводит пользователя по ключевому сценарию и даёт только базовые возможности.

Job Stories — Growth

Решения для Job Stories увеличивают ценность продукта. Без них он может существовать на этапе запуска, но их обслуживание критически важно для роста и развития бизнеса, привлечения новой аудитории и удержания старой.

Результаты исследования я заношу на доску в Figma.

1. Сперва фиксирую текущий процесс выполнения задач: указываю этапы, Job Stories и Desired Outcomes на каждом из них.
2. Во время анализа появляется много идей, как эти процессы можно оптимизировать. Записываю и их.
3. Дальше обсуждаю с командой возможные решения, и мы описываем оптимизированный процесс.
4. Затем дизайнеры рисуют макеты. Это существенно упрощает им работу, повышает прозрачность процесса и уровень понимания «чтобы что».
5. Составленные решения мы тестируем на глубинных интервью, собираем обратную связь, вносим корректировки, и дизайнер рисует финальные макеты для проведения usability-тестирования.

Чем помогает карта

1. Визуализирует весь продукт и его функциональность. Есть наглядная декомпозиция задач, и можно понять их реальный объём.
2. Формируется понимание, зачем нужна каждая функция в продукте и какую пользу она несёт. Это помогает снизить риски и затраты на разработку и поддержание функций с маленьким выхлопом.
3. Даёт хорошее представление о разных точках внедрения решений. Например, на каких этапах можно включить последовательный, логически выстроенный onboarding.
4. Позволяет строить конверсионные воронки и оптимизировать их.
5. Позволяет аргументировать свои решения руководству в удобочитаемом, визуальном формате.

Исследования — это глубокий аналитический процесс. Но вкладывая в них время, в будущем вы сэкономите гораздо бóльшее количество денег, своих или своей компании.

JTBD — прекрасный инструмент для разработки цифровых продуктов, но применимый только совместно с Desired Outcomes. Без них нет достаточной детализации, чтобы «взять и сделать».

Будет круто, если поделитесь своими мыслями на эту тему. Если кто-то уже использует JTBD, напишите о своём опыте в комментариях.

Я — Джей, занимаюсь дизайном интерфейсов и UX-исследованиями. Руковожу командой развития пользовательского опыта в Домклик.