Більшість SaaS-команд знають, що користувачі йдуть, перш ніж продукт встигає себе проявити. Вони бачать реєстрації. Вони бачать початок онбордингу. Вони бачать незавершені кроки налаштування, порожні панелі керування та «тихі» пробні акаунти, які ніколи не повертаються. Чого вони не завжди бачать, так це моменту, який так і не настав.
Саме тут стають у пригоді приклади «ага-моментів», але лише за умови їх правильного розуміння. Суть не в тому, щоб копіювати схему онбордингу іншого продукту. Суть у тому, щоб зрозуміти, як продукт переводить користувача від цікавості до першої цінності, а потім перетворює цю цінність на активацію користувача.
Користувач не активується через те, що пройшов тур. Він активується, коли продукт дає йому підставу повірити: «Це може вирішити проблему, заради якої я сюди прийшов».
Ця різниця має значення. Якщо ваша команда сприймає онбординг як навчання, ви будете пояснювати функції. Якщо ви сприймаєте онбординг як доказ, ви спроєктуєте найкоротший шлях до значущого результату.
Приклади «ага-моментів» — це не джерела натхнення
Більшість статей про «ага-моменти» повторюють одні й ті самі відомі приклади. Соціальний продукт стає кращим, коли користувач знаходить достатньо контактів. Інструмент для спільної роботи доводить свою цінність, коли команда починає працювати разом. Дизайнерський інструмент виправдовує себе, коли користувач швидко створює щось корисне.
Ці приклади не є помилковими. Вони просто занадто легко піддаються хибному тлумаченню.
Урок полягає не в тому, що кожен SaaS-продукт потребує розумного чек-листа чи дружнього туру. Урок у тому, що кожен сильний «ага-момент» має вимірювану структуру. Користувач виконує дію. Продукт видає видимий результат. Користувач розуміє, чому цей результат важливий.
Ця послідовність і є справжньою моделлю: дія -> результат -> цінність.
Якщо одна частина відсутня, «ага-момент» руйнується. Дія без видимого результату сприймається як налаштування. Результат без відчутної цінності виглядає як випадковий екран. Заява про цінність без взаємодії виглядає як маркетинг.
Корисний приклад «ага-моменту» — це не «користувач побачив панель керування». Це «користувач побачив на панелі керування те, що допомогло йому прийняти важливе для нього рішення».
Різниця між «ага-моментом», подією активації, рівнем активації та часом до отримання першої цінності
Ці терміни часто плутають, через що розмови про онбординг стають розмитими.
«Ага-момент» — це перше справжнє усвідомлення користувачем цінності продукту. Це частково емоційний досвід, але він не повинен залишатися абстрактним.
Подія активації — це спостережувана поведінка, яка свідчить про те, що «ага-момент» відбувся. Для продукту зі звітності це може бути створення першого корисного звіту. Для інструменту спільної роботи — запрошення колеги та отримання першого коментаря. Для SaaS-продукту в сфері нерухомості — перегляд робочого процесу, що вже адаптований під роль користувача.
Рівень активації — це відсоток нових користувачів, які досягають цієї події протягом визначеного часу. Це змушує команду бути чесною. Якщо 80% користувачів завершують онбординг, але лише 18% досягають події активації, онбординг не працює. Його просто «проходять».
Час до отримання першої цінності — це таймер. Він вимірює, скільки часу минає від реєстрації до першого значущого результату. Чим швидше, тим краще, але лише якщо цінність реальна. Швидка, але порожня панель керування все одно залишається порожньою.
Практичний висновок для SaaS-команд такий: не питайте «Чи завершили користувачі онбординг?». Питайте «Чи досягли користувачі результату, який доводить, чому цей продукт важливий?».
Три рівні «ага-моменту» в SaaS-продукті
Ефективний SaaS-продукт зазвичай потребує більше ніж одного моменту «ага!». Перший допомагає користувачам зрозуміти продукт. Другий — відчути його цінність. Третій — повернутися знову.
Перший рівень — це «ага!» на рівні вебсайту. Перш ніж користувач почне працювати з продуктом, він має впізнати в ньому себе. Сторінка повинна швидко демонструвати сценарій використання: роль користувача, його проблему та бажаний результат. Якщо продукт розрахований на кілька цільових аудиторій, загальна ціннісна пропозиція може виявитися занадто слабкою. Брокеру, керуючому нерухомістю, інвестору та операційному менеджеру можуть знадобитися різні докази ефективності.
Другий рівень — це «ага!» на рівні продукту. Це найважливіший етап. Користувач має взаємодіяти з продуктом і бачити результат, а не просто читати про нього. Це часто вимагає контрольованого першого досвіду: зразків даних, попередньо заповненого контенту, підказок або демо-режиму, який уже нагадує реальну роботу користувача.
Третій рівень — це «ага!» на рівні звички. Це відбувається пізніше, коли продукт стає частиною повсякденного робочого процесу. Користувач повертається, тому що продукт тепер містить контекст, історію, прогрес або зв’язки, які знову знадобляться завтра.
Більшість SaaS-команд занадто багато інвестують у перший рівень і недостатньо опрацьовують другий. Вони добре пояснюють продукт, але перший досвід роботи з ним все одно вимагає від користувача забагато зусиль, перш ніж він побачить реальну користь.
Приклад SaaS у сфері нерухомості: від розпізнавання ролі до доказу цінності продукту
В одному проєкті SaaS для нерухомості проблема полягала не просто в тому, що користувачам потрібен був зручніший процес онбордингу. Глибша проблема була в тому, що різні користувачі мали бачити різну цінність.
Універсальний шлях реєстрації ставився б до всіх однаково. Це спростило б пояснення продукту всередині команди, але ускладнило б його розуміння для користувачів. Першим завданням було розділити профілі користувачів і переконатися, що кожен може швидко впізнати шлях, який відповідає його роботі.
Це і було «ага!» на рівні вебсайту: «Це саме для таких, як я».
«Ага!» на рівні продукту вимагало іншого підходу. Замість того, щоб кидати користувачів у порожній інтерфейс і просити все налаштувати, досвід мав базуватися на попередньо заповненому демо-стані. Користувач міг одразу побачити реалістичний контент, відповідні приклади та робочий процес, який був достатньо близьким до його власного, щоб зробити цінність продукту відчутною.
Це було важливо, оскільки SaaS-продукти в нерухомості часто страждають від «порожнього стану». Якщо користувачеві потрібно додати об’єкти, контакти, документи, сценарії або робочі процеси, перш ніж станеться щось корисне, перша сесія відчувається як нудна адміністративна робота. Продукт може бути потужним, але користувач спочатку відчуває навантаження, а не винагороду.
Ефективніша модель — це контрольоване підтвердження цінності. Перший досвід має дати користувачеві три речі послідовно:
Сигнал: «Цей продукт розуміє мою ситуацію».
Дія: «Я можу зробити одну корисну річ, не налаштовуючи всю систему».
Винагорода: «Я бачу результат, якого було б важко досягти без цього продукту».
У SaaS-продукті для нерухомості це може означати, що користувач обирає свою роль, бачить попередньо заповнений сценарій об’єкта, актуальний для цієї ролі, змінює одну змінну і одразу бачить, як змінюється рекомендація або робочий процес. Момент «ага!» — це не вибір ролі. Це не демо-екран. Це момент, коли користувач бачить, як продукт реагує на реальний сценарій, і думає: «Це допоможе мені приймати кращі рішення».
Це набагато сильніше, ніж «заповніть свій профіль» або «подивіться цю екскурсію». Це дозволяє продукту довести свою цінність через взаємодію.
Що насправді демонструють сильні приклади моментів «ага!»
Хороші приклади моментів «ага!» корисні тоді, коли вони розкривають механізм роботи. Бренд менш важливий, ніж структура першого досвіду отримання цінності.
Loom: перше надіслане відео, а не сам інструмент запису
Головна перевага Loom не в тому, що користувач може записати екран. Запис екрана — це лише функція. Цінність з’являється тоді, коли користувач надсилає коротке відео й розуміє, що воно замінило зустріч, довге повідомлення чи заплутане пояснення.
Сигнал — це знайома багатьом проблема: «Це простіше показати, ніж пояснити». Дія — запис і надсилання короткого відео. Винагорода — можливість для іншої людини зрозуміти контекст без додаткової зустрічі.
Для SaaS-команд урок полягає в тому, що момент «ага!» може настати після першої дії, коли користувач бачить соціальний або робочий ефект від неї. Якщо ви вимірюєте лише «відео записано», ви можете пропустити важливіший етап активації: перше відео, яке було надіслано та переглянуто.
Headspace: перший план, який здається персоналізованим
Headspace — це не B2B SaaS-продукт, але його онбординг містить корисний урок для будь-якого продукту з різними мотиваціями користувачів. Момент «ага!» настає не тоді, коли ви пояснюєте кожну категорію медитацій. Він настає, коли ви ставите кілька особистих запитань і пропонуєте план, який виглядає індивідуальним.
Сигнал: «Цей продукт розуміє, навіщо я тут». Дія — відповіді на кілька простих запитань. Винагорода — рекомендований шлях, який зменшує невизначеність і полегшує початок першого сеансу.
Для SaaS-команд це важливо, коли різні типи користувачів потребують різних доказів цінності. Засновник, операційний менеджер, аналітик і менеджер з роботи з клієнтами можуть використовувати один і той самий продукт, але момент першої цінності не повинен виглядати однаково для кожного з них. Персоналізація — це не прикраса. Це спосіб, у який продукт обирає, яку цінність продемонструвати першою.
Sprout Social: перший корисний звіт ще до повного налаштування
Інструменти для керування соціальними мережами можуть бути складними для розуміння, якщо на старті вони порожні. Якщо користувачу потрібно підключити акаунти, імпортувати дані, налаштувати дашборди та вивчити інтерфейс, перш ніж побачити хоч щось корисне, перший сеанс перетворюється на роботу.
Ефективніша модель «ага!» — швидко показати реалістичний звіт. Сигнал: «Цей продукт може структурувати вашу активність у соцмережах». Дія — вивчення або коригування звіту. Винагорода — конкретне уявлення про результати, на збір яких вручну пішло б значно більше часу.
Урок простий: якщо цінність вашого продукту залежить від даних, не дозволяйте першому досвіду бути «порожнім». Використовуйте зразки даних, безпечні демо-дані або керований перший імпорт, щоб показати, як виглядатиме «користь» після налаштування.
Grubhub: перший локальний результат після одного запиту
Grubhub — це не SaaS, але це чудовий приклад швидкої першої цінності. Користувач вводить адресу й одразу бачить відповідні варіанти поруч. Дія невелика. Результат конкретний. Цінність очевидна.
Це працює, тому що продукт не починає з пояснення того, як працює маркетплейс. Він запитує лише те, що потрібно для користі, а потім видає результат, який відповідає контексту користувача.
Для SaaS-команд відповідне запитання звучить незручно, але воно корисне: який мінімальний ввід потрібен вашому продукту, щоб показати щось релевантне? Якщо відповідь — «повний процес налаштування», момент «ага!» ймовірно, занадто далеко.
Twilio: перше успішне надсилання
Інструменти для розробників часто мають іншу проблему з активацією. Користувач може розуміти обіцянку, але цінність залишається теоретичною, доки продукт не запрацює в його руках.
Для такого продукту, як Twilio, момент «ага!» — це не читання документації чи створення акаунта. Це надсилання першого повідомлення, здійснення першого дзвінка або успішний перший API-запит. Сигнал — технічна можливість. Дія — невеликий крок впровадження. Винагорода — доказ того, що система працює.
Урок для технічних SaaS-продуктів полягає в тому, що пояснення рідко перевершують успішний перший запуск. Якщо користувач може безпечно протестувати основний механізм на ранньому етапі, продукт здобуває довіру швидше, ніж будь-яка екскурсія функціями.
Як читати ці приклади, не копіюючи їх
Ці приклади вказують на п'ять повторюваних патернів.
Перший — це результат. Користувач створює, надсилає, генерує, публікує або завершує щось. Це працює, коли цінністю продукту є готовий артефакт: звіт, дизайн, відео, пропозиція чи сторінка.
Другий — це ясність. Продукт показує користувачеві те, що раніше було важко побачити. Це підходить для аналітичних, операційних, фінансових інструментів та інструментів у сфері нерухомості. Винагорода тут — не файл, а більш зважене рішення.
Третій — це зв'язок. Продукт стає цінним, коли інша людина бачить, відповідає, схвалює, приєднується або робить свій внесок. Це працює для інструментів спільної роботи, систем керування робочими процесами та продуктів, де цінність для одного користувача обмежена.
Четвертий — це персоналізація. Продукт доводить свою цінність, адаптуючись до ролі, мети, даних або контексту користувача. Це важливо для SaaS-продуктів з багатьма типами користувачів, де загальний шлях онбордингу змушує кожного витрачати зусилля на адаптацію під себе.
П'ятий — це робочий доказ. Користувач бачить, як продукт працює в реалістичному сценарії, перш ніж переходити до повного налаштування. Це важливо, коли продукт складний, насичений даними або його важко зрозуміти, дивлячись на порожню панель керування.
Практичне питання полягає не в тому, «який відомий онбординг нам скопіювати?», а в тому, «який саме доказ цінності наш продукт має надати користувачеві найпершим?»
Як спроєктувати шлях до першої цінності швидше
Щойно перший доказ стає зрозумілим, онбординг слід перебудувати навколо нього.
Зазвичай це означає видалення або відкладення всього, що не допомагає користувачеві отримати першу цінність. Повне налаштування профілю може почекати. Навчання другорядним функціям може почекати. Складні налаштування можуть почекати. Перша сесія не повинна охоплювати весь продукт одразу.
Для складних SaaS-продуктів це не завжди означає спрощення самого продукту. Це означає створення більш контрольованого шляху до першої цінності.
Використовуйте зразки даних, якщо реальні дані потребують забагато часу. Використовуйте вибір ролі, якщо різним типам користувачів потрібні різні шляхи. Використовуйте попередньо заповнені демо-стани, якщо продукт важко зрозуміти, коли він порожній. Використовуйте одну спрямовану дію, якщо повна панель керування викликає розгубленість. Використовуйте поетапне налаштування, якщо конфігурація необхідна, але не є цінною одразу.
Питання не в тому, «як показати користувачам усе?», а в тому, «який найменший чесний досвід доводить, що продукт може допомогти?»
Це слово має значення: чесний. Попередньо заповнене демо не повинно імітувати цінність, яку реальний продукт не може надати. Воно має скоротити дистанцію між наміром користувача та реальною корисністю продукту.
Що це означає для вашого наступного рішення щодо онбордингу
Найкращі SaaS-команди не проєктують онбординг навколо інформації. Вони проєктують його навколо доказів.
Вони знають, чого хоче досягти користувач. Вони знають, яка перша дія може принести видиму цінність. Вони знають, як виміряти, чи досягають користувачі цієї дії. Вони знають, скільки часу це займає. І вони знають, що має відбутися далі, щоб перша перемога стала звичкою.
Це і є справжнє використання прикладів «ага-моментів». Вони не є шаблонами. Вони є діагностичними інструментами. Кожен із них має допомогти вашій команді поставити більш влучне запитання: що є першим переконливим доказом цінності для нашого користувача?
Для простого продукту цей доказ може з'явитися за один клік. Для складного SaaS-продукту це може вимагати сегментації, попередньо заповнених сценаріїв або клікабельного прототипу для тестування кількох шляхів до першої цінності, перш ніж розробники розпочнуть роботу. У будь-якому разі принцип той самий: користувачі не повинні збирати цінність продукту по частинах, перш ніж зможуть її відчути.
Якщо ваша команда не впевнена, де має статися «ага-момент», ця невизначеність уже є сигналом від продукту. Структурований UX- та продуктовий аудит допоможе відобразити ланцюжок цінності, визначити гіпотези активації та протестувати, який потік створює найчіткіший шлях від першої цінності до активації користувача.
Ознайомтеся з UX-аудитом та дизайном цифрових продуктів від Flying Age
.svg){kind=logo}
