Якщо важко оцінити етапи проєкту, в беклогу з’являються прогалини, зривається запланований реліз, а команда не може домовитися, хто найбільше вкладає в продукт, то час освоїти новий інструмент: карту історій користувача User Story Mapping.
Завдяки цій техніці в команди складається наочне розуміння цілісної картини проєкту, поділеної на спринти: від ідеї до реалізації. Візуальне оформлення допомагає побачити взаємозв’язок між окремими етапами, правильно розставити пріоритети й не пропустити важливі задачі.
Зі статті дізнаєтеся, як підготуватися до сесії з User Story Mapping, кого покликати на зустріч, і як супроводжувати процес, щоб досягти хорошого результату.
Що таке User Story Mapping
Технологія створення карт — чудовий спосіб зібрати всіх зацікавлених у проєкті осіб, поставити задачі, візуально відобразити як виглядає подорож користувача продуктом. Список вимог (беклог) формують й оформлюють спільними зусиллями стейкхолдерів, це квінтесенція всього, що ви знаєте про користувачів: де вони почуваються впевнено в продукті, а де — ні, які задачі та дії пріоритетніші.
В основі карти користувача лежать три інструменти: User Persona, User Story і User Journey:
- User Persona — це опис конкретного користувача, з цілями та проблемами, які герой сподівається вирішити за допомогою продукту. Можливих користувачів можна розглядати індивідуально за персонами або групами: casual user, business user, powerful user.
- User Story — це 1-2 пропозиції про те, чого хоче досягти людина, використовуючи ваш продукт, що користувач може робити в системі. Зазвичай історії створюють за таким шаблоном: «Як хтось (роль) я хочу (мета/бажання), щоб (вигода)».
Наприклад, хочу натиснути кнопку, щоб залишити свої дані й отримати безкоштовну книгу. Інший, технічний формат створення історії, націлений на те, як спростити клієнту виконання дій, які часто використовуються, надати потрібний результат у «два кліки».
- User Journey — опис задач і дій клієнта, його досвіду, емоцій, думок на всіх етапах взаємодії з продуктом. Кроки користувача продумують, а потім фіксують у зручному для команди варіанті: на папері, в форматі Trello-дошки або візуалізації в MIRO. Кроки User Journey будуть необхідні для створення скелета-основи User Story Mapping.
Створюють User Journey люди, які безпосередньо працюють із користувачами: UI та UX фахівці, маркетингова чи продуктова команда, аналітики, user research фахівці, проєктні менеджери.
Чим корисна карта історій користувача:
- зберігає фокус на клієнті та його просуванні по продукту;
- візуалізує кроки користувача (User Journey);
- наочно показує зв’язок дій клієнта з User Story;
- дає побачити додаткові можливості, що призводить до появи хороших ідей;
- формує загальне розуміння у всіх стейкхолдерів.
Після сесії з User Story Mapping усі зацікавлені особи вийдуть із кімнати з однаковим сформованим розумінням: що ми робимо, для кого конкретно, як виглядають кроки створення потрібної реальності й навіщо це користувачеві.
User Journey: практичний приклад
Розглянемо ситуацію, коли людина купує онлайн-квиток у кіно, а потім обмінює електронну версію на реальний квиток у касі кінотеатру. Які дії за порядком повинен зробити користувач?
Список кроків (User Journey) може виглядати так:
Зайти на сайт → авторизуватися → вибрати фільм → вибрати дату й час → підібрати місця → вказати кількість квитків → сплатити → дістатися до кінотеатру → постояти в черзі на обмін → увійти до зали → знайти місце → подивитися фільм.
Цей перелік має включати всі кроки для досягнення потрібного результату, причому подивитися фільм — це не обов’язково кінцева мета. Можливо, користувач хоче купити квиток онлайн, щоб:
- отримати паперовий квиток і подарувати комусь;
- обміняти на паперовий варіант і прийти подивитися фільм через тиждень;
- відправити на email другові — це може бути вашою crazy idea, яка пізніше стане додатковою фічею.
Першочерговий пункт, який ви записали в User Journey, може бути точкою входу користувача: як у сам продукт, так і в одну з його фіч. Наприклад, всім користувачам потрібно відкрити програму або сайт, але способів зайти на екран з вибором квитків може бути кілька.
Як готуватись до User Story Mapping
Щоб зустріч вийшла продуктивною, заздалегідь передбачте кілька речей: достатня кількість часу, список учасників, місце для проведення.
Кого запрошувати на зустріч
На першу сесію збирайте стейкхолдерів, які дивляться на продукт із різних позицій:
- Представників користувачів: тих, хто складав User Journey або людей з досвідом користувача, фахівців підтримки, які допомагають клієнтам проходити всі етапи.
- Якщо в компанії є relationship менеджери, user researchers, обов’язково запросіть їх, тому що вони знають, що користувачі вже вміють робити, а де поки відчувають складності.
- Представників команд розробки, які зможуть донести результати сесії решті співробітників.
- Product owner-ів, представників бізнесу, зацікавлених у отриманні вигоди з того, що ви робите, та приймають рішення про релізи.
- Спеціалістів UI та UX;
- Архітекторів, щоб підказали стейкхолдерам черговість змін.
Підготуйте базову схему
Побудуйте скелет-основу — User Journey, набір усіх кроків, які користувач зробить по продукту плюс дії в кожному кроці:
- Верхня горизонтальна лінія, “хребет” — це User Journey, кроки клієнта, записані в тому порядку, в якому людина їх виконує.
- Вертикальні лінії, “ребра” — деталі-дії для кожного кроку, побудовані за пріоритетністю зверху донизу.
Організуйте робочий простір
Для сесії знадобиться онлайн або офлайн дошка й різнокольорові стікери для позначення різних задач або активностей.
Наприклад: шлях користувача — зелені стікери, те, що буде в User Story — жовтим, можливі складнощі — червоним, всі побажання бізнесу про пріоритети або релізи — невеликі яскраві наклейки розміром з чверть стікера.
Коли стейкхолдери зайдуть у кімнату, там повинно бути підготовлено все необхідне процесу:
- Зразок-легенда: розміщені на окремому місці приклади стікерів з написом на кожному, що він означає, щоб люди розуміли, який колір навіщо використовувати.
- Паркувальне місце – простір для питань і запису потенційно можливих складнощів.
- Територія для самої карти: в офлайн це може бути спеціальна дошка, стіна або навіть вікно.
- Місце для crazy ideas праворуч від картки. Там записують ідеї, які виникли у процесі обговорення і, можливо, їх вдасться запровадити у майбутньому.
- Куточок даних – data corner. Тут буде інформація про user persona. Коли доповнюють якусь фічу, дані для неї теж поміщають у data corner. У прикладі з покупкою квитка в кіно, це може бути аналітика: який відсоток користувачів купує квитки не для себе, що люди роблять із квитком після оплати.
Для побудови карти віддалено використовуйте діджитал-інструменти:
- Cardboardit.com;
- Storiesonboard.com;
- Featuremap.co;
- Craft.io;
- MIRO.
Як проводити User Story Mapping
Попередню підготовку проведено: прописано покроковий шлях користувача, зібрано інформацію про клієнта, складено портрети персон. Простір для проведення організовано належним чином. Залишилося покликати стейкхолдерів і розпочати сесію.
Візуально карта історій на всіх трьох етапах виглядає як горизонтальна лінія «хребта» й вертикальні «ребра», але цілі для кожної стадії побудови будуть різними.
1. Створення деталей
User Journey готують заздалегідь і розміщують кроки в порядку виконання: на малюнку це горизонтальна лінія із червоними квадратами. Зелені стікери – дії, – створюються безпосередньо на зустрічі разом із учасниками. Тривалість такої сесії – близько 4 годин.
Мета: Створити деталі, які користувач пройде на кожному кроці.
У прикладі з кінотеатром горизонтальна червона лінія — це послідовність всіх кроків людини при оплаті й отриманні квитка.
Тепер потрібно опрацювати вертикальні «ребра» до кожного кроку. Які приклади історій користувача можна придумати для етапу, коли користувач вибирає місце на сайті або в додатку?
Наприклад:
- «Я хочу побачити вільні місця, щоб мати можливість вибрати найближче до виходу, найкомфортніше».
- «Я хочу побачити схему залу, щоб вибрати зручні місця для великої компанії».
Продумуючи приклади, зважайте на два сценарії для кожної дії: у користувача все вийшло або нічого не вийшло.
На цьому етапі в data corner може з’явитися додаткова інформація:
- бізнес-цілі або больові точки;
- типи користувачів, які використовують цю систему;
- цілі чи болі користувача.
Фіксуйте всі ідеї, навіть найнеймовірніші у куточку для crazy ideas: наприклад, можливість для зареєстрованих користувачів бачити в першу чергу свої улюблені місця або бачити, куди взяли квитки друзі, якщо вони дали на це згоду. Ці фічі не будуть першочерговими, але через якийсь час їх можна впровадити у продукт. Тому такі ідеї теж візуалізують, щоб не втратити у процесі обговорення.
2. Уточнення підготовленої карти: refinement
Після того, як прописали всі дії, озвучили складнощі, зафіксували ідеї, саме час оцінити та пріоритизувати рішення. Для цього знову зберіть групу, трохи змінивши коло учасників. Правильно розставити пріоритети допоможуть представники трьох напрямків: бізнесу, користувачів, розробки. Виділіть окремим кольором те, що увійде до першого релізу, і лініями відокремте релізи один від одного.
За часом другий етап займає близько двох годин.
Мета: Виділити більш-менш важливі дії для вашого бізнесу і провести «червону лінію»: що увійде до першого, другого релізу або ітерації.
3. Опрацювання технічної складової
На цьому етапі команда розробників прописує функціональні деталі, які знадобляться користувачеві при кожній дії: фронтенд, бекенд та інші.
Дії системи створюють для кожної з персон-акторів. У прикладі з кінотеатром акторами можуть бути покупець квитка, друг, якому дарують квиток, касир, власник кінотеатру. У кожного актора є своя ціль і своя цінність у користуванні продуктом.
У той же час у команді розробки також є поділ на акторів за функціоналом: фронтенд, бекенд, тестування, дизайн. Над реалізацією кожної з фіч зазвичай працюють одразу кілька фахівців з різним обсягом роботи над фічею.
Правильно деталізувати й оцінити написане допоможуть розробник, тестувальник і відповідальний за досвід користувачів.
Мета: Визначити, які функції потрібні для мінімально життєздатного продукту, коротко сформулювати наміри: що система повинна робити для користувача.
Після проходження трьох етапів ви отримуєте готову картину для всіх команд. Починайте втілювати те, що запланували. Звертайтесь до карти протягом усього проєкту: додавайте нові деталі, оновлюйте пріоритети, відзначайте виконані задачі.
Чекліст із User Story Mapping
- Розмістіть кроки користувача (User Journey) горизонтально, щоб вийшла відповідь на запитання: «Що люди роблять з цією системою?»
- Переставте кроки в тому порядку, в якому користувач «подорожує продуктом».
- Під кроком-дією клієнта або кількома діями розпишіть User Story, які можна в разі потреби розділити на дрібні задачі.
- Шукайте дії, які здаються схожими, виконуються схожими людьми задля досягнення подібних цілей. Використовуйте різні кольори для визначення пріоритетності.
- Визначте, що увійде до першого релізу: список основних дій, які підтримує програма. Це може бути більш доопрацьований реліз або модель, яку називають «ходячий скелет» — програмне забезпечення, що підтримує найменшу кількість необхідних задач увесь час взаємодії з користувачем.
- Після кожного релізу вносьте зміни до загальної картини й заново пріоритезуйте задачі.
User Story Mapping допомагає гнучко керувати проєктами та працювати з вимогами замовника, представляючи їх наочно. Побудова карт користувача дозволяє правильно ставити і планувати задачі, враховувати зміни і, зрештою, збільшувати прибуток компанії.