JTBD и прочие схемы для технических историй

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

Неясно, что нужно бизнесу, что людям, неясен контекст использования:

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

Поехали :) Как отыскать человеческий смысл в сложной фиче? Как в итоге принести ценность пользователям и бизнесу?

Сначала — написать конкретные вопросы. Например:

Что пользователю нужно знать про сущности? Про сессии?
Зачем ему управлять сессиями? Как именно? (не считая разлогина)
В каких жизненных ситуациях ему это требуется? Все срочно и дорога каждая секунда? (злоумышленник пытается украсть деньги) Или это спокойное изучение статистики?
На каких страницах нашей биржи пользователь находится? Или он находится в письме? Или еще где-то?

И еще много вопросов. Мне надо как-то понять, что я "покрыл" вопросами всё содержимое фичи, и не осталось белых пятен. Как этого добиться?

Рисуем логическую схему

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

Что есть в фиче? Сессии, в них создаются сущности, у сущностей есть типы.

Делаем схему:

Пока недостаточно хорошо читается. Надо бы допилить. Быстренько пробуем по всякому:

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

Что дальше?

Добавил данные и действия

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

Дорисовываем:

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

А что дальше? Мне хочется перейти к интерфейсам, но пока рано. Надо понять, жизненные истории пользователя пользователя.

Расписал истории (бегло)

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

Накидываю верхнеуровневый сценарий:

Что-то фигово читается. Надо додизайнить:

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

Но все равно сыровато. Подкрутим:

Лучше читается очередность действий. Пустые сценарии перестали мешаться.

Но можно еще докрутить:

Нормально, переходим наконец к жизненным историям.

Перечисляем по-быстрому, просто выкидываем мысли из головы на схему:

Для начала нормально, можно сделать первую прикидку по экранам и блокам.

Спланировал интерфейсы

Накидал, какие интерфейсы мне понадобятся. Скопировал к ним инфу про контент и действия:

Некоторые названия — собирательные.

Например, "точки входа" — это не конкретный экран, а все места, откуда можно попасть в нашу фичу (письмо, уведомление, ссылка с какой-то другой страницы и пр).

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

Покажу основную часть покрупнее:

Удобно. Видно, какие данные на каких страницах расположены. Какие действия доступны.

Часть страниц еще непонятна и их надо прорабатывать, какие-то вопросы уже помечены красным.

Когда схема будет доделана — на нее будет очень удобно опираться. Можно даже передать ее другому дизайнеру, и он нарисует нормально.

Пройдусь еще раз по историям и пойду валидировать всё с коллегами.

Описал JTBD как их видел

Помните, я выше показывал набор историй? Вот этот:

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

Я выбрал формат Jobs To Be Done
(в конце я дам ссылку на хорошую статью про него):

Удобный формат:

показывает и состояние пользователя, и его задачу, которую мы должны выполнить, и желаемый конечный результат;
в "когда" можно добавить важный контекст использования. К примеру, указать, что устройство — мобилка и сделать упор на адаптиве или взаимодействии с мобильным приложением, или добавить QR-код и пр;
в "для того, чтобы" добавляем конечную цель, которую будем достигать и замерять по ней метрики. И которая подскажет выражения для копирайтинга и пр.

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

После этого я хотел доделать список интерфейсов, но не успел — поймался стейкхолдер и мы сели валидировать мои схемы.

Валидация со стейкхоледром

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

Вверху полная начальная схемка, внизу — итоговая.

Что в сухом остатке

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

Что полезного можно почитать по теме

Я использовал фреймворк JTBD в части схем.
Вот хорошая статья от Ани Булдаковой
Я использовал логические схемы, чтобы понять, какие сущности есть в фиче и как они связаны. Это упрощенный вариант concept map

Как научиться рисовать схемы:

Понравилось, как я решаю проблемы с помощью схем?

Читайте мой канал в телеграм: https://t.me/uxboost
Приходите на мой курс по схемам: www.uxboost.school (лучше всего написать в телеграм в личку и спросить о следующих потоках)
Пишите в личку (телеграм @Serebrennikov_I) и записывайтесь на индивидуальный менторинг