В UX-дизайне существует мощный инструмент — Customer Journey Map, карта пути пользователя. Это визуальное представление связанных Use Cases, которые выполняются в системе для достижения итоговой цели.
CJM, по сути, представляет собой скелет, где в роли костей выступают действия, а ткани организма — это информация, требуемая для их выполнения, или результаты этих действий.
Построение карты помогает:
- лучше увидеть процесс и его узкие места
- продумать точки получения информации и выполнения действий
- проработать итоговую визуализацию пользовательского процесса
- улучшить пользовательский опыт
CJM — это некоторая квинтэссенция пользовательских действий и пользовательских мыслей, выраженная визуально.
В случае проектирования интерфейса бизнес-приложения, из CJM можно исключить вещи, которые считаются необходимыми в общем случае: портрет клиента или метрики «успеха» (возврата, завершения). В бизнес-приложении путь будет выполнен в любом случае, и будет многократно повторён, что немного облегчает жизнь. В этом смысле CJM будет гораздо правильнее называть User Flow, но карта пути пользователя намного более часто употребляемый термин, да и тогда не получился бы такой заголовок.
В целом, CJM бизнес-приложения во многом схожа с описанием бизнес-процесса, отсюда и более привычная форма оформления в виде блок-схемы. Но, поскольку CJM вещь всё таки больше для внутреннего пользования, то чёткое следование нотациям не обязательно, главное общее и одинаковое понимание картины внутри команды. При этом блок-схема отнюдь не единственная возможная визуализация карты пользователя: они неплохо ложатся и в кросс-таблицы.
Инструментов для создания множество: от специализированных, типа uxpressia, до любого редактора с блоками и стрелочками, типа Figma. Или вообще чего-то экселеподобного, если Вы хотите оформить карту в виде таблицы. Я вот больше всего люблю рисовать на бумаге ручкой, но удалёнка накладывает и тут свой отпечаток: стал чаще пользоваться Miro.
Построение CJM начинается с двух блоков: точки входа и точки выхода. И расширяется по мере многократного повторения вопроса "Что ещё нужно, чтобы попасть из точки А в точку B?"
Для более практического примера я воспользуюсь опытом, в несколько упрощённом варианте, который получил в рамках реализации одного проекта некоторое время назад: рабочее место менеджера по продажам компании, специализирующейся на автомобильных запчастях. Почему не условное ERP? Ну, разбирать интерфейс ERP можно очень долго, а лучше он от этого не станет. Так что хотелось бы про что-то более вменяемое
Что ж, шаг 1. Заказчик озвучил вполне логичное требование: надо, чтобы менеджер смог обработать обращение контрагента и выставить ему счета на оплату. Очень упрощённо, но тем не менее, Запомнили.
Шаг 2. Менеджеру вообще надо понять, что это за контрагент. А для этого необходимо выделить определить сценарии, по которым обращение может оказаться у менеджера. В рассматриваемом случае их оказалось два: телефон и электронная почта. В первом случае идентификатором выступает ИНН или наименование контрагента, сообщаемые в начале разговора. ИНН наиболее часто встречаемый вариант. Во втором - адрес, с которого была отправлена почта.
В рамках третьего шага заказчику приходит понимание: покупка не всегда является целью звонка, иногда это уточнение информации по уже сделанным заказам. И в нашем пользовательском пути появляется ветвление. И заодно осознание: для оказания консультации нет необходимости осуществлять переход в другое место, можно всё сделать в рамках общего рабочего стола.
Четвёртый шаг. Определение информации, которая нужна менеджеру для оказания консультации по уже созданным заказам. Понимаем, что это статус оплаты — в компании было обычно не принято отгружать товар без хотя бы частичной предоплаты. А также статус доставки: дата отправки, сроки, какая транспортная компания, номер отправления.
Шаг 5. Переходим к тому, что заказчика интересовало больше всего — выставлению счёта. В рамках процесса сбора требований выясняется, что
- необходимо проверить наличие сильно просроченных оплат, как не закрытых на момент обращения, так и в прошлом — это являлось блоком для выполнения дальнейших операций.
- осуществить подбор позиций, в рамках которого сильно поможет
наличие топа из уже заказанных товаров — значительная часть постоянных клиентов заказывает одни и те же запчасти
быстрый подбор аналогов позициям из топа — на случай подорожания или долгого срока поставки
также необходимо сохранить возможность ручного подбора - определить наличие и доступность выбранных позиций
что есть в наличии на складе компании
что можно заказать у поставщиков и в какие сроки - определить сроки и размер оплаты, зависящие от условий договора — сумма предоплаты, сроки
Ну и последним шагом в процессе составления карты дошли до того, что выставление счёта не единственный результат работы менеджера, который можно автоматизировать. Скорее это целый пакет документов, который включает в себя бронирование позиций под контрагента, заказы поставщикам, накладные и да, те самые счета.
Да, полученное описание User Flow не содержит точек выхода «по отказу», если, предположим, для данного контрагента действует какое-то ограничение на поставку. Данное действие выходит за рамки работы с системой, это письменное или устное оповещение, что компания на текущий момент не работает с этим покупателем.
Да, по своей сути — это достаточно простой процесс сбора требований, результатом которого стала достаточно простая блок-схема. Но при этом полученный результат очень сильно помогает как в разработке: элементы UI-дизайна начинают сами выстраиваться в голове, так и при последующей поддержке решения и изменения процесса.