Як перетворити мапу користувацького досвіду на план дій?

Спілкуючись з дизайнерами я помітив, що не всі розуміють, як застосовувати Customer Journey Map на практиці. Це мене наштовхнуло на думку написати пост та поділитися своїм досвідом.

Disclaimer: тут і далі під Customer Journey Map (CJM), або ж мапою користувацького (клієнтського) досвіду мається на увазі покрокова візуалізована взаємодія користувача з продуктом чи сервісом задля досягнення мети на різних каналах та впродовж певного часу.

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

Перш за все, проектуючи продукт чи сервіс нам варто враховувати, що ми не є його користувачами. Інсайдерські знання про те, як система працює з середини не дозволяють нам об’єктивно розібратися в тому, як насправді користувачі взаємодіють з продуктом. Та яку задачу вони хочуть вирішити взаємодіючи з ним.

Це чудово звучить в теорії, але на практиці іноді побудова артефакту нічого не змінює. Адже його цінність є незрозумілою для всіх інших учасників команди, в тому числі — й стейкхолдерам.

Знайома ситуація?

Згоден, це дуже демотивує. Однак, часто ми можемо переконати команду та стейкхолдерів в цінності CJM. Дизайн-мислення тут стане нам в допомозі.

Чому побудова Customer Journey Map може завести у глухий кут?

Кожен фахівець має зону своєї відповідальності і мало розуміється на тому, чим займаються «сусіди по цеху». Уявіть, що розробник відмовляє нам у реалізації покращення, бо воно потребуватиме переписування монолітного ядра на таке, що складається з мікросервісів. Навряд чи ми б зрозуміли, наскільки це важливою та складною є наша пропозиція з точки зору розробників.

І так скрізь. Бізнес мислить цифрами і грошима. Продуктові менеджери також мислять цифрами, бо вони переводять бізнес-метрики у продуктові. Розробники, в свою чергу, також мають метрики, за якими вони оцінюють ефективність своєї роботи. Тому для кращої комунікації важливості користувацького досвіду нам також слід перейти на мову цифр.

Якими метриками спілкується дизайн?

Ми часто уникаємо використання цифр для оцінки ефективності нашого рішення. Позаяк, метрики дозволяють нам зрозуміти, чи рухаємось ми в правильну сторону і якщо так, то як далеко ми просунулись вперед.

Водночас я не часто бачу, щоб до кроків CJM додавали кількісні показники. Мені здається, що причина полягає в тому, що мапа користувацького досвіду — це артефакт якісного дослідження. І має місце популярне упередження, що кількісні дослідження більш ефективні за якісні, і взагалі їх не варто об’єднувати. Виправте мене будь ласка, якщо я помиляюсь, але я таку точку зору чув неодноразово, в тому числі у наших та західних дослідницьких спільнотах.

Особисто я займаю протилежну точку зору і погоджуюсь з Jared M. Spool ↓

Якісне дослідження відповідає на запитання що і чому, а кількісне — наскільки великою є виявлена проблема.

Як використовувати CJM для покращення користувацького досвіду на практиці?

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

Уявімо, що ми працюємо на сервіс продажу і доставки побутової хімії та продовольчих товарів, який шукає точки для росту бізнесу. А саме — нові сегменти клієнтів, на яких він може заробити, пропонуючи свої послуги. Від нас же бізнес очікує, що у нього зросте кількість клієнтів, які задоволені сервісом доставки.

Під час нашого дослідження ми ідентифікували групу людей від 30 до 40 років, які мешкають в районах без гарного продуктового ринку в пішохідній доступності, обожнюють готувати, але водночас дуже зайняті і працюють по 16 годин на добу. Ми створили персону для цього сегменту, назвали її Ігорем та визначили Customer Journey Map для сценарію приготування борщу. В результаті у ми отримали наступне ↓

Цей приклад є дуже спрощений. Тому працюючи над реальним проектом, я б не рекомендував би настільки детально вказувати сценарій.

Отже, в моєму розумінні процес перетворення мапи на план дій складається з п’яти кроків.

Крок 1: додаємо кількісні показники

Побудувавши CJM, зверніть будь ласка увагу що емоційна складова, потреби та проблеми на кожному кроці не дають нам розуміння, наскільки великою є проблема та чи слід зосереджувати наші зусилля саме на цьому місці. Тому їх слід заміряти кількісними метриками щоб використовувати їх як KPI.

В своїй практиці я дійшов до висновку, що можна використовувати як одну так і декілька метрик. Це залежить від контексту та загального напрямку розвитку продукту чи сервісу. Єдине, що на мій погляд комплексні загальні метрики на кшталт System Usability Scale (SUS) чи Net Promoter Score (NPS) для цього не підходять.

На цьому прикладі я буду використовувати коефіцієнт задоволеності користувачів, або ж Customer Satisfaction Score (CSAT). Він полягає у тому, щоб отримати відсоток задоволених респондентів, яким було поставлено питання «Оцініть будь ласка, наскільки ви задоволені [продуктом / сервісом / послугами, тощо]» з відповідями від 1 ( «дуже незадоволений») до 5 («дуже задоволений»). Формула вираховування коефіцієнту виглядає так ↓

(кількість користувачів що відповіли «4» або «5» ÷ загальну кількість респондентів) × 100 = % задоволених користувачів

Як наслідок, наші заміри виявились як на зображенні нижче ↓

Крок 2: ідентифікуємо проблемні місця

На цьому кроці дуже важливо, щоб всі члени команди однаково розуміли критичність. Адже деякі метрики мають свою специфіку в залежності від контексту.

Наприклад, час заповнення банківської реєстраційної форми представником транснаціональної корпорації буде відрізнятися від часу заповнення форми фізичною особою. Адже бізнесам слід передавати детальну інформацію про складну структуру власності. Але яка швидкість є настільки критичною для користувачів в обох прикладах, що команді варто витрачати зусилля на покращення цього кроку?

Для аналізу та визначення першочергових місць покращення можна використовувати будь який підхід. Але давайте на цьому прикладі пріоритизуємо наші результати використовуючи систему кольорових прапорців:

1. 🟩 Зелений прапорець — все добре та йде за планом.
   Для прикладу, нехай CSAT буде в діапазоні 80–100%.
2. 🟨 Жовтий прапорець — є проблема, але її вирішення може почекати.
   CSAT нехай буде в діапазоні 40–79%.
3. 🟥 Червоний прапорець — проблема є критичною, бо наш продукт на цьому кроці працює незадовільно і її треба вирішувати в першу чергу.
   CSAT в діапазоні 0–39%.

Інакше кажучи, ми перетворюємо мапу користувацького досвіду у свого роду воронку. Напевно це не найкраща аналогія, але її можна використовувати для комунікації зі стейкхолдерами.

Наприклад, якщо на другому кроці користувача змушувати заповнювати довгу реєстраційну форму, то він чи вона покинуть сайт та поїдуть зі списком на ринок. Як наслідок — це буде корелювати з показниками бізнесу, адже кількість реєстрації нових користувачів не буде показувати росту.

Отже, крок №2 є нашою першочерговою задачею, а витрачати зусилля на крок №4 поки що немає сенсу.

Крок 3: формулюємо гіпотези для покращення зручності

Після того, як ми розібралися, що саме викликає фрустрацію на кроці №2, саме час придумати рішення, яке може виправити проблему. Однак ми точно не знаємо, наскільки воно буде ефективним, тому краще сформулювати гіпотезу для перевірки.

Я використовую формат гіпотез з Lean UX, бо він містить критерії в самому формулюванні. Це дозволяє використовувати числові показники, щоб зрозуміти, чи рішення є ефективним.

Формат гіпотези:

Ми припускаємо, що [ця фіча] для [цих користувачів] призведе до досягнення [цього бізнес-результату].

Ми дізнаємось, що ми [були праві / помилялися], коли побачимо [якісні чи кількісні відгуки].

Так як наша задача — це знаходження точок зростання бізнесу, то й результат буде залежати від кількості задоволених користувачів. Тому ми можемо припустити, що сервіс доставки овочів допоможе як бізнесу, так й Ігорю досягти своєї мети. Отже, перша частина нашої гіпотези буде виглядати так:

Ми припускаємо, що сервіс доставки овочів для Ігоря, менеджера, який працює 16 годин на добу, полюбляє готувати та не має поруч продуктового ринку, призведе до збільшення задоволених користувачів цього сегменту.

Зверніть увагу, що у формулюванні цього бізнес-результату немає кількісного показника. Справа в тому, що «задоволеність» має досить широке значення. Можна мати можливість замовляти овочі і все одно бути незадоволеним через якісь інші причини. Ми ще не знаємо, які саме, бо виходимо в новий сегмент і не зрозуміло, як наш процес доставки себе покаже з овочами.

Часто трапляється що покращення є складним, комплексним та потребуватиме великих зусиль для запуску, на кшталт нового сервісу чи продукту. Тому є сенс головну гіпотезу розділити на декілька суб-гіпотез по-менше. Однак в такому випадку краще щоб суб-гіпотези стосувалися конкретних кроків — це дозволить швидше отримувати фідбек.

Крок 4: вираховуємо, як можна перевірити гіпотезу за найменшу кількість часу

Виводити на ринок повноцінний продукт чи сервіс дуже дорого і довго, тому нам не варто чекати весь цей час, поки він опиниться у користувачів. Для перевірки гіпотези нам допоможе «крива правди». Її роботу на практиці я проілюструю так.

Уявімо, що загальна вартість запуску нашого сервісу доставки овочів для цього сегменту буде коштувати $500 000. Це всі витрати включно з нашою роботою, команди розробників, відділу логістики, закупки, найму додаткових кур’єрів та рекламної кампанії.

Але що станеться, якщо ми помилилися? Якою буде ціна помилки, якщо виявиться, що доставка овочів цьому сегменту не потрібна або потрібна, але не в цьому форматі? Ми просто візьмемо і спалимо бізнесу гроші, які могли бути використані на щось корисніше.

Ми можемо перевірити цю гіпотезу набагато дешевше. Та суттєво зменшити ризики того, що щось піде не так. Наприклад, ми можемо створити прототип у Figma чи іншому редакторі, показати його нашим «Ігорям» та отримати у них відгук про реальний, хоч і ще не запущений, продукт.

Якою буде ціна помилки, якщо на стадії прототипування виявиться, що наше рішення не вирішує проблеми користувачів? Однозначно нижчою, ніж півмільйона доларів за повноцінний запуск. І бізнес у цьому зацікавлений, бо хіба ви багато бачили бізнесменів, які готові спалити півляма доларів просто так?

Отже, йдучи кривою правди, ми поступово рухаємось вперед, ускладнюємо нашу версію продукту й отримуємо при цьому відгуки від користувачів.

Перший крок перевірки нашої гіпотези — це розуміння, що ми можемо зробити в певних часових рамках. Скажімо, у нас немає двох місяців на на повноцінне дослідження, однак ми можемо собі дозволити:

1. півгодини цього тижня
2. годину наступного тижня
3. Один день наступного місяця.

Який метод валідації ми можемо використати? Їх також існує багато, я б радив би подивитися сюди для старту і вибрати підходящий.

Крок 5: заміряємо результат та порівнюємо з тим, що було

Уявімо, що цього тижня у нас є лише півгодини для перевірки гіпотези. На додачу, ми знайшли користувачів, які потрапляють під опис категорії Ігоря. І вже сьогодні зранку один з них зголосився допомогти (і отримати купон на ₴100, але це вже деталі).

Але як ми перевіримо, що наша гіпотеза вірна всього за півгодини? Тут нам допоможе друга частина гіпотези з Lean UX: Ми дізнаємось, що ми [були праві / помилялися], коли побачимо [якісні чи кількісні відгуки].

Ми використовуємо Customer Satisfaction Score (CSAT) як основну метрику, тому наприклад, можна користувачу дати список категорій товарів, які сервіс доставляє зараз та поміряти задоволеність нинішнім сервісом. Після цього показати користувачу оновлений список з категорією «овочі» і поміряти CSAT ще раз. Або використати будь який інший метод, який краще вирішить задачу за такий час. Зараз це не важливо, просто слідкуйте за логікою.

Уявімо, що ми з командою домовились, що вивід CSAT на другому кроці з червоної зони в жовту буде означати, що ми рухаємось в правильному напрямку. Як наслідок, наше твердження гіпотези тепер виглядає таким чином:

Ми припускаємо, що сервіс доставки овочів для Ігоря, менеджера, який працює 16 годин на добу, полюбляє готувати та не має поруч продуктового ринку, призведе до збільшення задоволених користувачів цього сегменту.

Ми дізнаємось, що ми були праві, коли побачимо збільшення CSAT з 22% → 40% у першого користувача, якому ми показали оновлений список категорій наших товарів.

Якщо ми отримали підтвердження правоти нашої гіпотези, ми можемо рухатись вперед і показати цей список більшій категорії користувачів, щоб отримати статистично коректний показник. А вже потім проектувати прототипи, ітеративно покращуючи юзер флоу та валідуючи найризиковіші гіпотези.

Якщо ж ми не отримали позитивного відгуку, то нам слід повернутися назад і переглянути як рішення, так і методологію оцінки. Можливо ми категорію назвали так, що вона незрозуміла користувачам? Чи можливо, краще було б використати інший метод для валідації? Або ж взагалі використання CSAT як основної метрики було помилкою з самого початку і це звело нас з пантелику?

На ці запитання неможливо відповісти без занурення в продукт. Але сам факт того, що отримати зелене світло працювати над сервісом в умовний понеділок та отримати відгук від користувача в той самий день — безцінно. Ми зекономили бізнесу гроші, в той же час нашим користувачам — не нашкодили.

Як наслідок, наша мапа користувацького досвіду не є статичним документом та з часом буде виглядати приблизно таким чином ↓

Однак зверніть, будь-ласка, увагу, що ми нашим рішенням змінюємо поведінку користувача. І він чи вона замість того, щоб їхати на ринок, користується нашим сервісом отримуючи зовсім інший досвід.

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

Бережіть себе! 🙌🏻 🇺🇦

Тренінг Lean UX Canvas

В листопаді 2021 року я проводив перший публічний тренінг по LUXC. Він отримав дуже гарні відгуки, тому я планую його повторити цього року декілька разів. Війна трішки змінила плани, тому я його планую провести літом ’22 року.

Чому варто потрапити?

На тренінгу ми пройдемось по Lean UX Canvas секція за секцією та випробуємо його в роботі. В тому числі:

1. Побачимо на власному досвіді, як будується customer-centric дискусія в команді.
2. Дізнаємось яка інформація необхідна для розуміння що є проблемою і для кого ми її вирішуємо.
3. Порівняємо проблему бізнесу та побажання користувачів на практиці.
4. Навчимося формулювати проблеми та гіпотези.
5. Розберемось що таке MVP і чому його варто використовувати для валідації рішення.
6. Побачимо в чому різниця між «мокапами» (outputs) та результатами нашого рішення (outcomes).

Кому буде корисно?

1. UX, Product та Service дизайнерам;
2. Дизайн лідам та менеджерам;
3. Продуктовим менеджерам;
4. Фаундерам стартапів.

Формат: онлайн
Тривалість: ~6 годин
Мова: українська або ж англійська
Як потрапити: заповність будь ласка форму нижче щоб я міг з вами сконтактувати як тільки з’явиться інформація по датам ↓

[Попередній запис на тренінг Lean UX Canvas | Літо 2022, TBD]