Разработка продуктов при помощи Job Stories

Руководитель мобильных продуктов Сбербанка для бизнеса Кирилл Гурбанов в своем блоге опубликовал перевод статьи Алана Клемента о том, с какой точки зрения подходить к проектированию продуктов. Делимся им на AppTractor.ru с разрешения Кирилла.

Раньше, когда между пользователями и разработчиками зияла пропасть, моделирование персон и создание пользовательских историй давало результат. Теперь все иначе.

Эта статья Алана Клемента, евангелиста Jobs to be Done, о том, как команда разработчиков проектировала страницу профиля в приложении, используя метод Job Stories. Его суть — в проработке реальных историй того, как продукт выполняет ту или иную работу.

Традиционно с информацией о пользователях сайта и их предпочтениях работали маркетологи, биздевы или продажники. Они собирали данные, упаковывали их и передавали разработчикам.

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

Клейтон Кристенсен из Гарвардской школы бизнеса предложил концепцию Jobs to Be Done («Какую работу выполняет продукт?»). По его мнению, мы «нанимаем» продукты и услуги, чтобы решать задачи. А значит разработчикам нужно обратить внимание на причины поведения пользователей, их проблемы и мотивацию. Метод Job Stories — один из способов эффективно использовать этот подход в работе над функциональными элементами продукта и его пользовательским интерфейсом.

Что не так с персонами?

Основная проблема: персоны вымышленные, а их характеристики имеют мало отношения к тому, как реальные пользователи принимают те или иные решения. Обобщенные демографические показатели (возраст, пол, цвет кожи, как проводит время на выходных), которыми обычно описывают персонажей, не помогают понять, почему, например, кто-то купил сникерс.. Но если мы знаем, что человек голоден, и у него  есть всего минута, чтобы заскочить в магазин, то всё становится понятнее.

А что с User Stories?

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

1. Тут есть персона.
2. Реализация неразрывно связана с мотивацией и результатом.
3. Не учитывается контекст, ситуации и страхи.

Часто функции или UX оказываются неэффективным. Если в их основе лежит пользовательская история, бывает сложно понять, в чем проблема — ведь она продиктована мотивацией и результатом. Что пошло не так? Произошла ошибка в реализации? Или предположения о мотивах были неверными?

Что такое Job Story?

Job Story — это особый метод работы над продуктовыми фичами, его UX и UI. Пол Адамс впервые упомянул о концепции Job Story здесь, а подробнее рассказал здесь. Но как применять этот подход на практике?

Вот пример:

1. Начните с высокоуровневой задачи.
2. Определите одну или несколько задач поменьше, которые помогли бы решить задачу уровнем выше.
3. Понаблюдайте, как люди решают данную проблему сейчас (какие действия они выполняют).
4. Сформулируйте одну или несколько Job Stories. Отразите в них причины, страхи и стимулы пользователей.
5. Найдите решение, функциональное или интерфейсное, которое закроет данную Job Story.

Рассмотрим пример разработки интерфейса профиля продавца-консультанта в приложении для работников автосалона. Приложение помогает продавцу рассчитать стоимость кредита для клиента и оформить заявку.

Разработка страницы профиля

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

«Вот профиль продавца», — сказал он, указывая на один из блоков.

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

Зачем нужен профиль? Если нужен, то где он должен быть? Какую информацию он дает? В каких ситуациях он будет полезен? Какую работу выполняет?

Чтобы ответить на эти вопросы, команда решила применить метод Job Stories.

Примечание: для простоты мы рассмотрим только одну «историю» для профиля, хотя в процессе рассматривалось несколько «историй».

1. Начните с высокоуровневой задачи

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

2. Определите одну или несколько задач поменьше или такую, которые помогли бы решить задачу уровнем выше

Чтобы оформить заявку на кредит, продавец и покупатель должны заполнить много бумаг: информацию об автомобиле, условия кредита и другие данные, которые могут быть достаточно “интимными”. Клиент захочет быть уверен, что его финансовые сведения конфиденциальны и надежно защищены.

3. Понаблюдайте, как люди решают данную проблему сейчас

Прежде чем предоставить свои данные, покупатель обычно оценивает на глаз, можно ли доверять автосалону и его сотрудникам. А удостоверившись, заполняет бумаги под надзором продавца и без свидетелей.

4. Сформулируйте одну или несколько Job Stories

Изложите в них причины, страхи и стимулы пользователей.

1. Взаимодействуя с продавцом через приложение…
2. …покупатель захочет знать, что компании и ее сотрудникам можно доверять, а процесс оформления безопасен.
3. Продавец захочет быть уверен, что процесс оформления не заставит клиента нервничать…
4. …чтобы тот не усомнился, стоит ли передавать продавцу свои данные.

Эта история описывает общую ситуацию. В нее можно добавить деталей и уточнить контекст. Например, действие может происходить у клиента дома, а не в салоне. Или проработать сложности при создании профиля и работе с ним.

5. Найдите решение

Добавьте новую фичу или внесите изменения в интерфейс, чтобы история разрешилась желаемым образом.

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

1. Клиент должен всегда видеть в приложении профиль продавца, как будто он рядом. Это снизит уровень тревоги.
2. В профиле должна быть фотография продавца, его должность и информация о том, как давно он работает в компании и сколько машин продал. Это поможет клиенту довериться сотруднику.
3. В профиле должны быть указаны контактные данные для связи с продавцом. Кроме телефона и почты нужна кнопка «Задать вопрос [продавцу]». Это даст клиенту возможность удостовериться, что он верно заполнил все документы.

Вот пример интерфейса:

А вот для чего нужен каждый его элемент:

Когда интерфейс готов, мы видим, как пользователь взаимодействует с ним и что получает: уверенность в том, что его личные данные будут в целости и сохранности.

Проектирование приложений с учетом реальных условий и ситуаций

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

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