Руководитель мобильных продуктов Сбербанка для бизнеса Кирилл Гурбанов в своем блоге опубликовал перевод статьи Алана Клемента о том, с какой точки зрения подходить к проектированию продуктов. Делимся им на AppTractor.ru с разрешения Кирилла.
Раньше, когда между пользователями и разработчиками зияла пропасть, моделирование персон и создание пользовательских историй давало результат. Теперь все иначе.
Эта статья Алана Клемента, евангелиста Jobs to be Done, о том, как команда разработчиков проектировала страницу профиля в приложении, используя метод Job Stories. Его суть — в проработке реальных историй того, как продукт выполняет ту или иную работу.
Традиционно с информацией о пользователях сайта и их предпочтениях работали маркетологи, биздевы или продажники. Они собирали данные, упаковывали их и передавали разработчикам.
Однако в таком процессе теряются важные нюансы. Чем обусловлены действия пользователей, что их волнует, что мотивирует? Чтобы лучше понять пользователей, разработчикам следует научиться распознавать их эмоции и откликаться на них.
Клейтон Кристенсен из Гарвардской школы бизнеса предложил концепцию Jobs to Be Done («Какую работу выполняет продукт?»). По его мнению, мы «нанимаем» продукты и услуги, чтобы решать задачи. А значит разработчикам нужно обратить внимание на причины поведения пользователей, их проблемы и мотивацию. Метод Job Stories — один из способов эффективно использовать этот подход в работе над функциональными элементами продукта и его пользовательским интерфейсом.
Что не так с персонами?
Основная проблема: персоны вымышленные, а их характеристики имеют мало отношения к тому, как реальные пользователи принимают те или иные решения. Обобщенные демографические показатели (возраст, пол, цвет кожи, как проводит время на выходных), которыми обычно описывают персонажей, не помогают понять, почему, например, кто-то купил сникерс.. Но если мы знаем, что человек голоден, и у него есть всего минута, чтобы заскочить в магазин, то всё становится понятнее.
А что с User Stories?
Вот пользовательская история: пользуясь функцией резервного копирования, я могу исключить некоторые папки, чтобы сэкономить место в хранилище. В ней есть три проблемы:
- Тут есть персона.
- Реализация неразрывно связана с мотивацией и результатом.
- Не учитывается контекст, ситуации и страхи.
Часто функции или UX оказываются неэффективным. Если в их основе лежит пользовательская история, бывает сложно понять, в чем проблема — ведь она продиктована мотивацией и результатом. Что пошло не так? Произошла ошибка в реализации? Или предположения о мотивах были неверными?
Что такое Job Story?
Job Story — это особый метод работы над продуктовыми фичами, его UX и UI. Пол Адамс впервые упомянул о концепции Job Story здесь, а подробнее рассказал здесь. Но как применять этот подход на практике?
Вот пример:
- Начните с высокоуровневой задачи.
- Определите одну или несколько задач поменьше, которые помогли бы решить задачу уровнем выше.
- Понаблюдайте, как люди решают данную проблему сейчас (какие действия они выполняют).
- Сформулируйте одну или несколько Job Stories. Отразите в них причины, страхи и стимулы пользователей.
- Найдите решение, функциональное или интерфейсное, которое закроет данную Job Story.
Рассмотрим пример разработки интерфейса профиля продавца-консультанта в приложении для работников автосалона. Приложение помогает продавцу рассчитать стоимость кредита для клиента и оформить заявку.
Разработка страницы профиля
Представим, что мы находимся на раннем этапе разработки продукта. Команда обсуждала возможный вид дашборда, когда один из разработчиков подошел к доске и нарисовал простую схему.
«Вот профиль продавца», — сказал он, указывая на один из блоков.
Выступающий объяснил свою идею, но убедить слушателей было непросто. Посыпались вопросы о каждом из элементов схемы. Началась оживленная дискуссия, но единогласия участники не достигли.
Зачем нужен профиль? Если нужен, то где он должен быть? Какую информацию он дает? В каких ситуациях он будет полезен? Какую работу выполняет?
Чтобы ответить на эти вопросы, команда решила применить метод Job Stories.
Примечание: для простоты мы рассмотрим только одну «историю» для профиля, хотя в процессе рассматривалось несколько «историй».
1. Начните с высокоуровневой задачи
В нашем случае задача — помочь продавцу оформить вместе с покупателем кредит. Обычно клиенту приходится заполнять много бумаг.
2. Определите одну или несколько задач поменьше или такую, которые помогли бы решить задачу уровнем выше
Чтобы оформить заявку на кредит, продавец и покупатель должны заполнить много бумаг: информацию об автомобиле, условия кредита и другие данные, которые могут быть достаточно “интимными”. Клиент захочет быть уверен, что его финансовые сведения конфиденциальны и надежно защищены.
3. Понаблюдайте, как люди решают данную проблему сейчас
Прежде чем предоставить свои данные, покупатель обычно оценивает на глаз, можно ли доверять автосалону и его сотрудникам. А удостоверившись, заполняет бумаги под надзором продавца и без свидетелей.
4. Сформулируйте одну или несколько Job Stories
Изложите в них причины, страхи и стимулы пользователей.
- Взаимодействуя с продавцом через приложение…
- …покупатель захочет знать, что компании и ее сотрудникам можно доверять, а процесс оформления безопасен.
- Продавец захочет быть уверен, что процесс оформления не заставит клиента нервничать…
- …чтобы тот не усомнился, стоит ли передавать продавцу свои данные.
Эта история описывает общую ситуацию. В нее можно добавить деталей и уточнить контекст. Например, действие может происходить у клиента дома, а не в салоне. Или проработать сложности при создании профиля и работе с ним.
5. Найдите решение
Добавьте новую фичу или внесите изменения в интерфейс, чтобы история разрешилась желаемым образом.
Чтобы решить описанную выше Job Story, команда определилась в том, какие фичи должны быть в Профиле, и как он должен выглядеть. Важно было соблюсти баланс: недостаток информации не позволит решить задачу, а избыток может привести к негативным эффектам. Обсуждение привело к следующим выводам:
- Клиент должен всегда видеть в приложении профиль продавца, как будто он рядом. Это снизит уровень тревоги.
- В профиле должна быть фотография продавца, его должность и информация о том, как давно он работает в компании и сколько машин продал. Это поможет клиенту довериться сотруднику.
- В профиле должны быть указаны контактные данные для связи с продавцом. Кроме телефона и почты нужна кнопка «Задать вопрос [продавцу]». Это даст клиенту возможность удостовериться, что он верно заполнил все документы.
Вот пример интерфейса:
А вот для чего нужен каждый его элемент:
Когда интерфейс готов, мы видим, как пользователь взаимодействует с ним и что получает: уверенность в том, что его личные данные будут в целости и сохранности.
Проектирование приложений с учетом реальных условий и ситуаций
Чтобы создавать полезные продукты, нужно быть внимательным к тому, как люди решают свои проблемы в реальной жизни: в каких обстоятельствах им приходится это делать, каковы их причины и какие эмоции ими движут.
Абстрактные свойства персонажей отвлекают команду от важного. Чтобы создавать эффективные инструменты, нужно копать глубже и изучать истории того, как продукты решают наши задачи. Концепция Job Stories помогает разработчикам понять, какие фичи нужны пользователю, и какой UX принесет ему наибольшую пользу.