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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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