Task Analysis в UX дизайне. Сравнение с CJM, User Flow & User story mapping

Есть такой UX метод - таск анализ (task analysis — анализ задачи). Он не особо популярен и весьма зря. Поэтому хочу немного о нем рассказать. Поделюсь личным опытом использования, и посмотрим чем он отличается от карты пути пользователя (cjm), юзер флоу (user flow) и карты пользовательских историй (user story mapping).

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

Task Analysis — это изучение действий, которые выполняют пользователи чтобы достичь своей цели.

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

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

Вообще вариантов куча, но в ux дизайне их обычно два:

А тем, что он помогает понять:

Итак,

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

Второе — проанализировать данные и построить диаграмму. Помните, что вы анализируете какую-то цель пользователя (например купить билеты на самолет онлайн на Бали). А у цели всегда есть начальная и конечная точки.

* Шаги пользователя анализируются по таким атрибутам как: иерархия, порядок действий, частота выполнения и когнитивная нагрузка (там, где пользователю нужно напрячь мозг и подумать).

Как построить диаграмму?

Теперь, когда вы построили диаграмму, она будет as is (т. е существующий процесс) — можете устраивать брейншторминг всей командой. Подумайте, какие шаги вы можете схлопнуть/ перенести/ или например добавить. Далее переработайте диаграмму в “to be” (т. е ваш целевой процесс).

Возможно, может показаться, что это трата времени (потому что скорее всего вы что-то подобное уже делали), но поверьте, визуализация данных таким образом существенно упрощает работу с продуктом. Команде наглядно видно что и как и зачем. Коммуникация улучшается, исчезают лишние вопросы.

За основу возьмем кейс, с которым я лично столкнулась месяц назад:

Собиралась бронировать жилье на airbnb, пока не увидела конскую комиссию. Написала хосту, договорилась и в итоге, мне было нужно перевести около 500$ на счет хоста в Индонезию. Мне дали и номер банковской карты и номер счета, еще посоветовали перевод через Wise или PayPal. В общем выбирай что хочешь, а деньг должны были перевестись.

Возьмем PayPal и попробуем провести таск анализ.

Расписываем все таски, которые нужно совершить, чтобы отправить перевод, например “зарегистрироваться” — “создать перевод” — «привязать банковскую карту» и тд.

Под тасками пишем сабтаски (советую детально) — например «ввести номер телефона» — «получить смс-подтверждение» — ввести email” и тд.

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

Пример так анализа перевода в PayPal:

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

Ты точно знаешь, что комиссия есть, потому что PayPal говорит: “эй, а ваш банк может взимать комиссию, но только вы сами узнайте сколько”. В итоге ты сидишь и думаешь, рискнуть и перевести или лучше оплатить через airbnb и не париться?!

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

Кстати, когда вы делаете таск анализ To Be, не обязательно сокращать количество шагов (это не всегда лучший клиентский опыт), главное, чтобы они были действительно нужными и делали ситуацию понятной для пользователя.

Таск анализ и карта пути пользователя (CJM) могут показаться схожими, но между ними есть разница.

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

С помощью CJM мы можем понять как пользователь начинает взаимодействовать с продуктом и почему; как это происходит на разных этапах; какие могут возникнуть проблемы на пути пользователя и что он в это время чувствует (страхи/ сомнения/ радость и тд). Обращает внимание на детали в разных точках соприкосновения и дает понимание, где именно есть проблемы

А таск анализ это больше об одной конкретной задаче, о последовательности действий пользователя в продукте с целью что-то сделать.

Вернемся к нашему кейсу: например, CJM может рассказать о том, как и почему пользователь начал взаимодействовать с Paysend; описать мысли и чувства, которые пользовать испытывает при использовании продукта.

Шаги в CJM могут быть следующие: Осознание проблемы (нужно совершить перевод) - Поиск вариантов перевода — Регистрация в Paysend — Создание перевода — Подтверждение перевода — Получение уведомления об успешном переводе и бронировании отеля.

Эти два понятия тоже похожи, но давайте глянем на различия.

Юзер флоу (User flow) — это визуализация последовательности действий пользователя по продукту. Он может быть построен как для конкретного функционала, так и для всего продукта. В нем, как правило, есть условия и выбор действий, которые обозначаются разветвлениями.

Например: по такс анализу PayPal мы поняли, что совершать перевод можно только по логину (номеру почты). Возможно у получателя нет аккаунта в PayPal и просить его создать только ради вашего перевода — это… ну такое себе.

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

Вначале я не могла разобрать, в чем, собственно, разница между этими двумя инструментами, но она есть.

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

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

Она может быть составлена как на весь продукт, так и на какой-то определенный функционал.

Составление такой карты это достаточно большой процесс, так как для ее построения нужно иметь три составляющие:

Карта строиться иерархически и состоит из следующих частей:

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

Небольшой пример из нашего кейса:

Итак, на втором шаге таск анализа мы видим, что возможность перевода у PayPal это только по номеру логина (почты).

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

Эпик: действие “Перевод” — которое будет состоять из нескольких шагов.

Юзер стори/ активити: “Начать перевод” — (т. е шаг, который нужно сделать).

Детали:

Дальше идет обсуждение и приоритизация этих фичей.

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

Далее проводим линию, которая определяет релизы. Все что находится над самой верхней линией — берем в работу. То, что ниже, делим на последующие релизы.