Перевірка нашої гіпотези не закінчується після запуску продукту чи його функціоналу
Ми створюємо продукти у світі, що змінюється ледь не щодня. Тому нам потрібно постійно слідкувати за взаємодією користувачів з продуктом. Адже їх потреби з часом можуть змінитися або еволюціонувати. Так само, як і цілі бізнесу.
Для відслідковування такої взаємодії ми використовуємо метрики на мапі клієнтського шляху.
Дієві та беззмістовні метрики
Вибираючи метрики для перевірки гіпотез звертайте, будь-ласка, увагу на те, чи можна на основі отриманих кількісних даних прийняти рішення.
Кількісні дані що вирвані з контексту та які не допомагають прийняти рішення є беззмістовними (у продуктовій спільноті це має назву vanity metric).
Найближчою анекдотичною ідіомою що демонструє беззмістовну метрику є «середня температура по лікарні». Спитайте себе, яке рішення ви можете прийняти знаючи середню температуру пацієнтів Київської Міської Клінічної Лікарні Швидкої Медичної Допомоги?
Протилежністю беззмістовних метрик є дієві метрики (англ. actionable metric).
Приклади беззмістовних метрик:
- Перегляд сторінок
- Тривалість перегляду сторінки
- Середня тривалість сесії
- Будь-яка метрика без контексту чи порівняння
Перетворення беззмістовної метрики на дієву
Є багато способів за допомогою яких ми можемо визначити чи наша метрика є беззмістовною, чи дієвою, але я вам пораджу ці два.
Спосіб №1: розповісти контекст використання метрики
«Ми переконалися що доставка товарів на вказаний час збільшить конверсію на 50%».
Це дуже амбітні результати які звучать чудово. Але якщо ви так скажете або бізнесу або продуктовим менеджерам, то одразу отримаєте від них запитання: «для кого?».
Тут ми: звісно, пригадаємо для кого ми робили це покращення, і скажемо що це було для сегмента, який уособлює одну з наших персон:
«Для Романа, прораба що робить ремонти в Києві та області».
На жаль, ані бізнесу, ані продуктовим менеджерам таких відомостей недостатньо для прийняття рішення. Тому з їх сторони однозначно точно послідує вбивче запитання: «і що з того?». І вони будуть праві.
Тут ми можемо пригадати матеріал попередніх лекцій де ми вираховували вартість поганого користувацького досвіду і використати, відповівши шось на кшталт:
«Ми підрахували, що на цей сегмент приходиться близько 100 незавершених покупок на місяць. Середній чек цих замовлень становить ~$1500. Отже, якщо ми праві, то це покращення дозволить бізнесу отримати (100×1500)/2 = ~$75,000 недоотриманого прибутку за місяць після релізу».
І це вже краще, хай навіть ми суттєво помилилися в наших розрахунках. Це не наша задача – рахувати точно, ми рахуємо приблизно. Але в цьому випадку такі дані допоможуть краще прийняти рішення.
Спосіб №2: порівняти результати з попереднім показником
Зробивши дослідження, ми комунікуємо бізнесу чи продуктовим менеджерам наші результати, що звучать приблизно так:
«Ми переконалися що покращення системи обліку товарів на складі змінить співвідношення кількості замовлених та повернутих товарів до 4:1».
Це також дуже амбітні результати, і звучать вони також чудово. Але чи можуть продуктові менеджери, чи бізнес прийняти рішення? Навряд чи, адже не зрозуміло чи зміна 4 до 1 це добре чи погано? В такому випадку з їх сторони буде адресовано наступне вбивче запитання: «у порівнянні з чим?»
Тому для того, щоб краще комунікувати результати наших досліджень, нам треба заміряти стан справ, який був до початку нашої роботи. Уявімо, що у нас є такі дані і ми відповідаємо, наприклад так:
«У порівнянні зі співвідношенням 2:1 у III кварталі 2022».
Таким чином, ми допоможемо бізнесу і продуктовим менеджерам прийняти рішення.
Дві групи дієвих метрик для перевірки гіпотез
- Метрика успіху: як ми зрозуміємо, що ми вирішили проблему бізнесу та/або користувачів?
- Метрики прогресу: як близько ми знаходимось до вирішення проблеми бізнесу та/або користувачів?
На мапі клієнтського шляху метрика успіху є відповідає кроку, що ми асоціюємо із задоволенням користувача від досягнення мети. Водночас метрики прогресу стосуються всіх інших кроків взаємодії з продуктом чи сервісом для досягнення мети.
На мапі клієнтського шляху можуть бути кроки, які виходять за зону відповідальності продуктової команди. Знання цих метрик може допомогти нам на ранніх етапах внутрішнього розслідування.
Але спитайте себе, чи може продуктова команда впливати на рекламний бюджет бізнесу? Навряд чи. Тому в подальшій роботі вони втрачають для нас зміст.
Дашборд дизайнерських метрик продукту
І бізнес, і продуктові менеджери та навіть розробники мають дашборди для відслідковування ефективності за допомогою кількісних даних. Тому нам, дизайнерам, треба мати свій.
Для створення цілісного розуміння впливу нашого продукту на досвід користувачів впродовж часу є сенс збирати ці метрики в окремій табличці — дашборді дизайнерських метрик. Таким чином ми розуміємо наскільки швидко чи повільно ми рухаємось до нашої мети.
Кольорові прапорці
З часом дуже легко потонути на такому дашборді, адже він буде перевантажений кількісними даними.
Тому для аналізу, комунікації та прийняття рішень можна використовувати систему кольорових прапорців.
- 🟩 Зелений прапорець — немає розбіжності, або несуттєва розбіжність між очікуваним та фактичним показником. Для прикладу, ми очікували збільшити CSAT з 50% до 85%, але отримали 80%.
- 🟨 Жовтий прапорець — розбіжність між очікуваним та фактичним показником не є значною. Для прикладу, ми очікували збільшити CSAT з 50% до 85%, але отримали 70%.
- 🟥 Червоний прапорець — розбіжність між очікуваним та фактичним показником є значною. Для прикладу, ми очікували збільшити CSAT з 50% до 85%, але він не змінився, зріс несуттєво до 55%, або ж взагалі зменшився до 40% тощо.
