Как Job Stories помогут в создании крутого интерфейса?

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

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

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

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

Создание персон все еще популярно в разработке новых продуктов. Маркетолог придумывает вымышленного персонажа и считает, что именно он будет использовать приложение (сервис, товар, услугу и т.п.). На первый взгляд кажется, что это хороший ориентир для разработки, если бы не одно «но». Эта персона вымышленная.

Поможет ли обобщенное описание потенциального клиента (пол, возраст, цвет кожи, любимый досуг и т.п.) понять, почему сегодня куплен букет роз в одном из магазинов? Но если будем знать, что у жены клиента сегодня день рождения, становится понятна мотивация покупки.

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

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

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

Персоны не работают, пользовательские истории тоже. Что же делать? Пришло время поговорить о Job Story — новом слове в проектировании и разработке пользовательских интерфейсов.

Job Story — это метод работы над продуктовыми фичами, их UX и UI. В основе лежит решение разных задач пользователей: скоротать время ожидания, получить доступ к нужному контенту и т.д. Метод впервые описал Пол Адамс. Позже он подробнее раскрыл свои мысли.

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

То есть User Story описывают функциональность продукта с точки зрения пользователя, а Job Story — выявляют одинаковые мотивы поведения разных людей в конкретных ситуациях.

Если хорошо поработать с Job Story и получить много сценариев, можно:

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

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

С теорией все просто, поэтому перейдем к практике. Посмотрите алгоритм использования Job Story в работе:

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

Кроме проработки Job Story, проводите небольшое JTBD-исследование (Jobs To Be Done — концепция, к которой относится Job Story). Вы копнете глубже, посмотрите на продукт с разных сторон и узнаете его по-настоящему. Для проведения исследования ответьте на несколько вопросов:

• Какие проблемы и потребности есть у целевой аудитории?
• Кто наши конкуренты?
• Как пользователи сравнивают нас с ними и почему выбирают конкретные решения?
• Какие потребности мы удовлетворяем, а какие нет?
• Как развивать продукт, чтобы приносить больше пользы и победить конкурентов?
• Как донести ценность решения до аудитории?

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

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

Обратите внимание, мы рассмотрим пример с одной историей. В реальности разрабатывают несколько вариантов и рассматривают каждый по отдельности.

Определяем высокоуровневую задачу

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

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

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

Анализируем, какими способами люди решают эту задачу сейчас

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

Сформулируем несколько Job Story, отразив в каждой причины, страхи и стимулы пользователей

Описываем одну или несколько Job Story, уделяя внимание причинам, страхам и стимулам потребителя:

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

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

Ищем оптимальное решение (функциональное или интерфейсное), которое закроет основную Job Story

Подумайте, что можно сделать для разрешения истории желаемым образом. Обычно помогает изменение интерфейса или добавление новой фичи. Кстати, не забывайте проверять нововведения на соответствие Feature/Product Fit.

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

На основе примера можно сделать несколько выводов:

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

На основе этих выводов делаем новый интерфейс или вносим правки в уже существующий. Далее отслеживаем, как пользователи взаимодействуют с продуктом, с какими проблемами сталкиваются и т.п. и вносим правки, чтобы приложение соответствовало product market fit.

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

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