Як проводити експерименти в ІТ-продукті: підходи та фреймворки. Ґайд від команди OBRIO

Олександр Личак, Head of Product в ІТ-компанії OBRIO з екосистеми Genesis, підготував для AIN.UA ґайд, як підготуватися та провести експерименти в ІТ-продукті. В ньому він спростував пʼять поширених міфів, поділився робочими кейсами, фреймворками та підходами, як наповнити беклог якісними ідеями та залучити до цього процесу всю команду. 

Nebula — це флагманський продукт OBRIO, багатоканальна астрологічна платформа з основним ринком у США. Мобільний застосунок має понад 21 млн завантажень.

5 міфів про експерименти

1. Прості зміни UI дадуть швидкий фінансовий результат.

2010 року Microsoft протестували десятки відтінків синього для пошуковика Bing. Правильний колір мав спонукати користувача переходити за посиланнями. Обравши «той самий» синій (до речі, дуже близький до кольору, що використовує Google), вони прорахували, що це може принести десятки мільйонів доларів доходу. Продовження цієї історії немає, але подібні кейси породили міф, що маленькі зміни, на кшталт зміни кольору чи шрифту, можуть дати значні результати. Щоби досягнути великої цілі, потрібно ітеративно покращувати досвід користувача протягом тривалого часу, запроваджуючи комплексні зміни. Лише системний підхід до експериментів дає найкращий результат.

2. Експерименти закінчуються на оптимізації CRO (Conversion Rate Optimization).

Часто компанії фокусують свої зусилля на оптимізації коефіцієнтів конверсії, проводячи 95% тестів на екранах sales/paywall. Вони переконані, що тільки CRO дає найкращі результати. Натомість бізнес — ультрамарафон, який проходить у найекстремальніших умовах. Щоби подолати його, ви мусите сфокусуватися на стратегічно важливих речах, а не просто на перших двох кілометрах гонки. CRO — важливий етап, який потрібно комбінувати з тестами, спрямованими на UX та Retention.

3. Фокус тільки на перемогах.

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

4. Тестувати — дешево, тому можна це робити швидко, просто й часто.

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

5. Експеримент дорівнює тесту.

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

• визначення великої цілі;
• ідеація (мозковий штурм) рішень;
• ітерація тестів та отримання знань;
• імплементація результатів.

Ідеація рішень: як наповнити беклог правильними гіпотезами

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

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

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

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

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

Ідеація — це процес формування ідей. У дизайн-мисленні є безліч методик, але в контексті нашої теми зупинимося на трьох підходах:

• модифікація дизайну (включає методи: «Викреслення», «Ціль на відстані трьох метрів», «Гучна меншість», «Девіантні користувачі»);
• psych фреймворк;
• прожарка CJM (Customer Journey Map).

Розглянемо їх детальніше.

4 методи модифікації дизайну

1. «Викреслення»

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

Frozen

2. «Ціль на відстані трьох метрів»

Порівняйте лендинги двох великих бізнесів: Zoho та Dropbox. Їхня різниця у Revenue складає 2,2 рази, а в Revenue per employee — 10 разів. 

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

3. «Гучна меншість»

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

4. «Девіантні користувачі»

Це ті користувачі, чия поведінка відрізняється від тієї, на яку ми очікуємо. Наприклад, вони чомусь пропускають етап онбордингу в застосунку. Компанія Reddit тестувала різні варіанти такого екрана. Ефективним виявилося глибоко розпитати користувачів про їхні потреби, щоби сформувати релевантну стрічку новин. В Nebula ми спробували схожу механіку для роботи з девіантними користувачами.

Psych-фреймворк: працюємо з мотивацією

Psych — умовна одиниця виміру мотивації користувача. Умовно її можна порівняти з паливом в автомобілі користувача, який «подорожує» вашим продуктом. Десь він витрачає паливо, а десь заправляє повний бак.

Дії, що витрачають «паливо»:

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

Як допомогти користувачу заправити бак:

• надати щось, що наближає його до цінності;
• мікронагороди на ранніх етапах (наприклад, цінні інсайти, корисна інформація)
• гра на емоціях чи бажаннях користувача за допомогою візуалу, копірайтингу тощо.

Наприклад, інтерфейс Amazon. Що тут може мотивувати користувача: знижка, вигідна пропозиція, кількість відгуків, високий рейтинг, легко одразу здійснити покупку, безпечна транзакція. Усе це підштовхує до покупки цього конкретного товару.

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

Прожарка CJM

CJM (Customer Journey Map) — візуалізація подорожі користувача продуктом. «Прожарка» — всебічний критичний розбір. Зазвичай цей процес має такі етапи:

1. Продакт-менеджер виступає ініціатором та модератором.

2. У прожарці бере участь уся команда за бажанням.

3. Шаблон складається з таких модулів:

• скриншоти кроку користувацького шляху;
• прогнозована емоція користувача (psych-фреймворк);
• зони зростання;
• способи покращення користувацького досвіду на кожному кроці;
• конкретні метрики, на які це може вплинути.

На практиці це виглядає таким чином:

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

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

Метод CJM Roast допомагає побачити ваш продукт зі сторони та дізнатися радикально інші точки зору (QA, Front-end дивляться на продукт інакше, ніж дизайнер). Також це чудовий спосіб залучити всю команду. Важливо, щоби всі однаково розуміли цінність продукту, чому відбуваються ті чи інші зміни, а також відчували причетність до результату. Це дуже корисна командна вправа, в OBRIO ми практикуємо її доволі часто.

Замість висновків

Загалом проведення експериментів допомагає створити налагоджену комунікацію в команді, дає розуміння, що відбувається в бізнесі, які використовуються підходи для вирішення різних проблем. Це культивує в команді data-driven-культуру, у якій заведено орієнтуватися на результат та застосовувати науковий підхід для прийняття рішень. Добре спланована програма експериментів слугує певним компасом та задає напрямок руху команди: які рішення приймати та до якої мети йти.

Автор: Олександр Личак, Head of Product в ІТ-компанії OBRIO