UX/UI дизайн для создания идеального продукта. Полный и исчерпывающий гид

Одним из первых это заметил Джефф Паттон и предложил один из лучших методов декомпозиции функциональности – картирование пользовательских историй (User Story Mapping), который он подробно описал в своей книге.[37]

Для этого функции продукта описываются в формате пользовательской истории (User Story[38]). Пользовательская история – способ описания функциональности в форме прямой речи с позиции пользователя. Шаблон описания такой: «Я как  могу , чтобы ». Например: «Я как могу , чтобы ».

Трудно описать все особенности метода. О нем очень хорошо изложено в книге, хотя мне, чтобы овладеть им, после прочтения потребовалось несколько сессий под руководством профессионалов. Основная идея заключается в том, что функциональность предстает в виде матрицы, где по горизонтали идут шаги, необходимые для достижения цели, а по вертикали – желательные особенности этого шага. После построения матрицы детали сортируются по принятым в команде критериям: важности для пользователя, важности для бизнеса и т. д. Далее выделяется MVP внутри отдельной функции.

У карты пользовательских историй (User Story Map) несколько уровней. Уровень типов пользователей, уровень активностей – это части маршрута, которые можно запускать по отдельности в разных релизах. Уровень нарратива – обязательная последовательность шагов. Уровень деталей – последовательность желательных особенностей на данном шаге

Шаблоны декомпозиции

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

Например, разбиения по операциям. Тогда пользовательская история: «Я как могу , чтобы » раскладывается на пять историй, связанных с операциями при работе со списком: добавление, удаление, чтение, редактирование и выбор элемента. Одна из историй будет такая: «Я как могу , чтобы ».

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

Пример декомпозиции пользовательской истории

В качестве примера декомпозиции возьмем историю: «Я как могу , чтобы ».

Пример того, какой интерфейс может спроектировать UX-дизайнер, не прибегая к шаблонам декомпозиции:

Теперь проведем декомпозицию и посмотрим, как изменится финальный дизайн.

Для начала прибегнем к разбиению по операциям и разделим работу со списком привязанных карт по известному акрониму CRUD: Create (добавить элемент), Read (просмотреть), Update (редактировать), Delete (удалить). В нашем случае добавляется еще одно действие – выбор активной карты, то есть к акрониму прирастает еще одна буква: CRUD+S, где Select – выбрать активный элемент списка.

Самое приоритетное действие – создание элемента списка. Вполне представим релиз продукта, в котором пользователи получают одну лишь возможность добавлять карту.

Пример результата декомпозиции по шаблону CRUD+S

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

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

Пример декомпозиции: «Я как могу  чтобы ». Карта пользовательских историй похожа на рыбный скелет, и потому минимально жизнеспособный релиз (Release 1) называют «позвоночная история»

Чтобы выявить такие менее значимые особенности реализации, воспользуемся инструментом картирования пользовательских историй:

Пример декомпозиции: «Я как могу , чтобы ». После декомпозиции в первый релиз пойдет только функция добавления карты, без удобств. Такая история может увидеть свет с учетом риска, что в те 1–2 недели, пока готовится следующий релиз, у пользователя возникнет потребность удалить привязанную карту