Бывает так, что при разработке IT-решений команды опираются лишь на техническое задание, не обсуждая будущий продукт с пользователями (подробнее о UX-интервью — в этой статье). Однако, в этом случае есть риск, что продукт не решит в полной мере проблемы последних и даже может создать для них новые «боли».
Для снижения этого риска важно продумать User story — сценарии работы пользователей с продуктом.
User story — это короткая история с описанием возможных вариантов применения продукта. Как правило, её совместно создают UX-дизайнеры, продуктовые дизайнеры или аналитики на этапе планирования разработки и развития проекта, при необходимости подключая заказчика.
С user story работают при проектировании новых продуктов, а также при анализе уже существующих, после этапа тестирования. Как правило, в процессе разработки команда не раз анализирует пользовательские истории и обновляет их, учитывая состояние продукта на данный момент. Кроме того, иногда в документе учитывают, какой будет функциональность продукта после внедрения планируемых изменений.
В user story необходимо определить:
— Цели пользователей. Расскажите, какие цели на самом деле преследуют пользователи при работе с продуктом.
— Результаты. Опишите, какие действия пользователь может выполнить при работе с продуктом.
При создании user story обычно используют доску с цветными стикерами, программы Miro или FigJam. Для того чтобы быстро ориентироваться в стикерах, используйте различные цвета для каждой строки, обозначающей действия, шаги и иные сведения. Далее рассмотрим этот процесс подробнее, опираясь на классические рекомендации Джеффа Паттона из книги «Пользовательские истории. Искусство гибкой разработки ПО».
Карты user story помогают определить, какие функциональности необходимо включить в MVP продукта, а какие можно реализовать на следующих этапах, что помогает команде расставить приоритеты.
User story описывает роль пользователя в продукте, его потребность и результат, который он получит, если событие произойдет. Для быстроты составления используется следующий шаблон:
“Я как (тип пользователя), хочу (действие или цель пользователя), чтобы (получить следующий результат или выгоду)”.
Рассмотрим на примере заказа дебетовой карты в онлайн-банке:
Я как пользователь online банка могу заказать дебетовую карту, чтобы не тратить время на поход в отделение.
Далее мы рисуем схему. Желательно при создании схемы отталкиваться от финального шага, иначе пользовательский сценарий может разветвляться с появлением побочных действий.
Важно в первую очередь расписать задачи пользователей. Так, ниже мы описали процесс заказа дебетовой карты через онлайн-банк.
После чего для каждой цели расписываются особенности каждого шага пользователя. В нашем примере указано, с чем сталкивается пользователь при оформлении карты, а также какие возможны варианты.
Так как история может иметь разветвления, в схему нередко добавляются прочие активности и роли персонажей. Мы разделили схему на 3 активности, а именно:
ознакомление с услугой;
первый вход в онлайн-банк;
- оформление дебетовой карты.
Теперь нам необходимо распределить планируемые функции в соответствии с предстоящими релизами продукта. Для начала определим, какая последовательность принесет максимальную ценность.
Так как в нашем примере задействована только одна категория пользователи, мы не расписывали в схеме роли. На практике для ролей обычно используют стикеры в форме ромбиков и смайлики для быстрой визуализации.
Теперь, когда истории готовы, оговорены и расписаны, можно переходить к следующим этапам разработки продукта.
Заключение
Работа с пользовательскими историями помогает UX-дизайнерам, аналитикам и всей команде в целом наиболее точно определить, каким должен быть продукт для удобства конечного потребителя. При этом User story отражают функции, концепцию продукта и перспективы его дальнейшего развития.
Возможно что-то не понял, но вот что увидел.
Результат который хочет получить пользователь "чтобы не тратить время на поход в отделение". Определяем последовательность которая принесёт максимум пользы. В получившейся последовательности получается, что не пойти в отделение пользователь сможет только после 3 релиза. При стандартных спринтах в 2 недели, только через 1,5 месяца после запуска продукта.
В итоге продукт сразу не даёт пользователю тот результат который он хочет.
P.S. И отсутствие СМС уведомления, в 1 релизе, явно будет добавлять % тревоги пользователю и заставит общаться с колл центром, что не в плюс для UX.
Кстати, шаблон “тип пользователя - объект - контекст” (я как пользователь хочу….) это вообще другая методология - Jobs-to-be-done
Небольшое уточнение. Шаблон из статьи - всё-таки user story.
Шаблон Job story выглядит так:
когда (описание ситуации, контекст),
я хочу (мотивация),
чтобы (результат).
Вы очень верно заметили) в перый релиз согласно методологии (и логике) должны войти те функции, которые позволят пройти путь от начала и до конца, пусть и с неудобствами (на первое время).
Если провести аналогию (из книги пользовательские истории) со средствами передвижения, то на первом релизе мы даём пользователю скейтборд - передвигаться можно, но не удобно. На втором велосипед - уде можно уехать дальше и тд. На последнем - машину)
Статья не до конца раскрывает суть инструмента) советую прочесть упомянутую книгу «Пользовательские истории» очень полезная.
Полезная информация, спасибо.
Комментарий удален модератором
Бывает так что люди до сих пор не понимают, что они используют OOUX вместо HCD. Да что там, многие UX- дизайнеры не в состоянии понять почему они сидят на ООП
Отсюда каша в головах.
Чтобы каждый релиз в проде, был полезен конечному пользователю - необходимо с этим пользователем жить и спать в одной кровате (уж простите за "сексизм").
У вас и всех нет бюджета и ресурса на честный HCD. Вы честно на коленке придумали, внутри команды размазали от "лица польователя" флоу или там карту эмпатий а потом после прода хоба - пилим срочно костыли ребята.