Job Stories для проектирования интерфейсов

https://blog.intercom.io/using-job-stories-design-features-ui-ux/
  • Перевод


Моделирование целевой аудитории (персонажей) и написание «пользовательских историй» (user story) были эффективными, когда клиенты и разработчики продуктов находились далеко друг от друга. Теперь все по-другому. В этом посте говорится о том, как одна команда разработчиков применила метод Job Stories для создания страницы профиля пользователя.

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

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

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

Проблема моделирования персонажей


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

Характеристики персонажей (возраст, пол, раса или способ проведения выходных) не объясняют, почему клиент, к примеру, съел батончик «Сникерс». Но тот факт, что у него ушло 30 секунд на покупку, и съев батончик, ему удалось заглушить чувство голода на 30 минут, напротив, дает объяснение.



Заголовок: «Почему Питер купил «Сникерс?»;

столбик слева: «Чтобы утолить голод»;

столбик справа: «Ему 35 лет, у него диплом маркетолога, он любит арахис, шоколад, нугу и карамель, он любит батончики «Сникерс» и съедает по одному каждый день. Он ведет активный образ жизни, у него 2 собаки. Он отдыхает в кафе Jack in the box, но покупает еду в Taco Bell. Он вывихнул палец на ноге»


Проблема метода user stories


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

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

Зачастую, какой-либо функционал или элемент интерфейса оказываются малоэффективными. Если они были разработаны с помощью метода User Story, то выяснить причину будет трудно, так как процесс реализации, мотивацию пользователя и результаты действия «свалили в одну кучу». Как в такой ситуации понять, что было сделано неправильно? Была ли допущена ошибка при учете реализации, или же были неправильными предположения по поводу мотивации? Подробнее о сложностях использования метода User Story.



Что такое Job Story




Впервые этот термин был упомянут Полом Адамсом (Paul Adams) и раскрыт более подробно здесь. Метод Job Stories — это иной способ работы с функционалом продукта, пользовательским интерфейсом и опытом взаимодействия. Но как команде разработчиков применить его в своей работе?

Вот один из подходов:

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

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

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




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

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

Это профиль продавца автомобилей.

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

Для чего у нашего приложения должная быть страница профиля? Почему она должна быть в этом месте или где-то еще? Какую информацию она должна показывать? Какие обстоятельства она учитывает и какую задачу выполняет?

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

Примечание: Для краткости в данной статье в основном будет рассматриваться только одна «история» для страницы профиля. На деле же были подготовлены несколько Job Stories.

1. Начните с задачи более высокого уровня

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

2. Определите второстепенные задачи

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

3. Проанализируйте процесс

(то, как пользователи решают рассматриваемую проблему в данное время – какую работу они проделывают сейчас)

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

Это позволяет ему чувствовать себя уверенным в том, что данные заполняются корректно, и их не получат люди, которым не следует их видеть.

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

(которые выявляют объективные причины, мотивацию действий пользователей и сложности, сопровождающие их)

Когда продавец и его клиент взаимодействуют друг с другом посредством данного приложения…

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

Вышесказанное формирует «историю» в рамках конкретной ситуации. Ее можно детализировать, добавив больше информации об обстоятельствах покупки, например, о том, где и когда будут заполняться документы (дома, либо в дилерском агентстве) — и сложностях, которые будут испытывать обе стороны при создании и просмотре профиля.

5. Разработайте решение

(обычно это какое-либо изменение функционала или интерфейса, которое учитывает проблемы, отраженные в «истории»)

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

  1. В процессе использования продукта профиль продавца должен быть доступен постоянно (чтобы уменьшить беспокойство клиента по поводу того, что он не находится рядом с продавцом).
  2. Подобный профиль должен будет содержать фотографию продавца, должность, количество проданных автомобилей и срок работы в компании (чтобы уменьшить беспокойство клиента по поводу того, является ли продавец компетентным и можно ли ему доверять).
  3. Данный профиль должен позволять легко выйти на контакт с продавцом. К примеру, в нем может быть указан номер телефона, адрес электронной почты и кнопка с надписью «Задать вопрос [Имя продавца]» (это уменьшает беспокойство клиента по поводу того, что без посторонней помощи он модет заполнить форму неправильно).

Вот пример решения:



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



Рисунок:

Надпись над фотографией («Ваш менеджер по продажам»), фото профиля и имя продавца: все это напоминает клиенту, кто такой Джои (Филгуд) и уменьшает беспокойство по поводу того, что он не находится рядом с продавцом.

Должность продавца: главный менеджер по продажам, количество проданных машин (500) и комментарий («8 лет в компании Грэйт Сэйлс»). Это подтверждает, что Джои компетентен, и другие люди ему доверяют.

Номер телефона, почтовый адрес и кнопка «Задать вопрос» — с Джои легко связаться, и это уменьшает беспокойство клиента по поводу того, что он не сможет самостоятельно заполнить форму.


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

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


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

Абстрактные характеристики пользователей и смешение понятий реализации, мотивации и результата действия — все это отвлекает команду разработчиков от сути работы. Если же команда идет дальше и исследует «Задачи, для решения которых пользователь «нанимает» продукт», она получает возможность принимать более удачные решения.

Использование Job Stories для создания функционала, пользовательского интерфейса и опыта взаимодействия является одним из способов достичь этого. О других решениях в данной сфере и не только – в нашем переводе книги UX-команды MailChimp.
  • +10
  • 16,4k
  • 2
Фонд развития интернет-инициатив 50,22
Экспертиза и инвестиции для стартапов
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Похожие публикации
Комментарии 2
  • 0
    столбик справа: «Ему 35 лет, у него диплом маркетолога, он любит арахис, шоколад, нугу и карамель, он любит батончики «Сникерс» и съедает по одному каждый день. Он ведет активный образ жизни, у него 2 собаки. Он отдыхает в кафе Jack in the box, но покупает еду в Taco Bell. Он вывихнул палец на ноге»

    Но это же не user story, это биография.

    Проблема метода user stories:
    — Они основаны на персонажах.
    — Они не учитывают разницу между выполнением действия, мотивацией и результатами действий.
    — Они не учитывают контекст ситуации, обстоятельства и проблемы пользователей.

    Как-раз таки они должны это учитывать, иначе это не user-story

    User story вытекает из биографии, и определяет потребности человека и контекст их выполнения, какие-то ограничения. То, как данный человек будет идти к своей цели и как какой-либо инструмент ему сможет облегчить путь до этой цели.
    • 0
      «Самая основная и наиболее частая проблема, возникающая при использовании метода моделирования персонажей такова: персонажи являются вымышленными». Дальше можно не читать. Почему нельзя провести фазу исследования и узнать, что же собственно в голове у пользователя? )) К чему эти танцы с бубном?

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое