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

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Привіт! Я Руслан — Growth Manager у мультипродуктовій IT-компанії PlantIn, що входить до екосистеми Genesis. Ми розвиваємо два мобільні застосунки, і я відповідаю за PlantIn — застосунок для ідентифікації рослин, що містить також поради з догляду за ними.

Сьогодні PlantIn — застосунок № 1 у своїй ніші у світі з понад 35 мільйонами користувачів. Його обирають за точність розпізнавання рослин і їхніх захворювань по фото, поради з догляду, які спрощують рутину, та зрозумілий функціонал. Щодня ми аналізуємо поведінку аудиторії, запускаємо гіпотези та вдосконалюємо користувацький досвід.

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

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

Ситуація в продукті: фідбек є, користі з нього мало

Тривалий час ми неправильно перетворювали зворотний звʼязок на інсайти, поки не зрозуміли: аби фідбек справді працював, він має бути частиною цілісної системи, а не просто полем «оцініть фічу та залиште коментар».

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

  • Різна поведінка. У застосунку багато точок збору фідбеку, але вони реалізовані по-різному: десь іконки, десь емодзі, десь лише текстовий відгук тощо. Відсутність єдиної логіки збільшує час на розробку та підтримку кожної окремої поведінки.
  • Фокус лише на негативі. Ми працюємо лише з негативним фідбеком, а на позитивний просто «дякуємо», хоча він міг би драйвити маркетинг чи працювати на зміцнення репутації.
  • Користувачам завжди потрібно писати «вручну». Це бар’єр, через який ми втрачаємо цінні думки, адже не всі готові витрачати час на розлогі фідбеки.
  • Навантаження на сапорт. До підтримки надходило все підряд: баги, фіч-реквести, питання. Це створювало шум, через який команда витрачала ресурси на несистемні запити замість того, щоб фокусуватися на дійсно критичних кейсах.
  • Імпульсивні рішення. Один випадковий коментар іноді ставав причиною створення нової фічі (без жодної валідації).

Тож ми ухвалили рішення зробити паузу й переглянути сам підхід.

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

Від точки фідбеку до системного процесу

Звісно, зворотний звʼязок існує постійно: користувачі лишають відгуки в App Store / Google Play, звертаються в сапорт, пишуть на сайтах з оглядами тощо. Однак ми вирішили розглядати фідбек не як окрему фічу, а як частину загального користувацького досвіду, коли йдеться про Customer Satisfaction загалом.

Ось який вигляд мав наш процес перебудови флоу.

  1. Аудит фідбек-точок. Ми зібрали всі місця в застосунку з будь-якими елементами зворотного зв’язку. Далі зафіксували, як вони виглядають, що запитують, як поводяться.
  2. Опитування користувачів, щоб краще дізнатися про досвід використання й очікування від продукту.
  3. Аналіз. Сегментували зібрані фідбеки за темами та болями за допомогою AI, щоб визначити ключові проблеми для кожного розділу.
  4. Бенчмаркінг. Дослідили, як працює фідбек у топових продуктах. Ми дивилися на дизайн, флоу, метафори, мікрокопі.
  5. Уніфікація флоу. На цьому етапі ми нагенерували концепти універсального, масштабованого фідбек-флоу, що легко адаптується до контексту екрана.

Хороший ретеншн ≠ 💚

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

Що ми змінили

Після аудиту та досліджень ми сформували новий системний підхід до зворотного звʼязку. Він об’єднує логіку фідбеку, рейтингу застосунку та звернень до служби підтримки. Наша мета — зробити користувацький досвід максимально простим, а фідбек — максимально інформативним для команди.

Ось ключові зміни:

  1. Стандартизували фідбек-флоу. Усі точки фідбеку працюють за єдиним принципом.
  2. Менше ручного вводу. Для кожної унікальної точки є 3-4 варіанти відповідей, які потрібно не вводити вручну, а обрати зі списку.
  3. Нові сценарії звернення в сапорт. Залежно від типу проблеми ми передбачили різні сценарії — від автоматичного редіректу на сторінку з релевантним рішенням до сповіщення в Slack для відповідального за фічу менеджера.
  4. Додали позитивні сценарії. Тепер задоволені користувачі можуть залишити оцінку в сторі, незадоволені — написати нам скаргу.

⭐️ Як обрати правильний момент для запиту рейтингу і водночас не втратити позиції в App Store і Google Play. Якщо є сумніви щодо вибору оптимального моменту для запиту фідбеку з перенаправленням в App Store, варто протестувати кілька сценаріїв і порівняти їхню ефективність. Це можна зробити за допомогою A/B-тестування модалки з оцінюванням у форматі зірочок. Якщо користувач ставить позитивну оцінку — перенаправляти в App Store. Якщо негативну — дати поле фідбеку всередині застосунку. Так ви зберете конструктивну критику, не ризикуючи рейтингом у сторах.

Але варто бути обережним: Apple може насваритись за маніпуляцію оцінками, тому ми використовуємо цю практику лише в межах А/Б-тестів і не впроваджуємо її системно.

P.S. Дизайн з емоджі конвертить в хорошу оцінку краще.

Як ми аналізуємо фідбек

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

Ось кілька наших підходів.

  1. Не фідбеком єдиним. Зворотний зв’язок — лише один з інструментів у нашому дослідницькому арсеналі. Щоб отримати справді цінні інсайти, ми поєднуємо його з низкою інших методів дослідження.
  2. Пострелізний аналіз. Для нових флоу ми порівнюємо фідбек до та після: дивимося, що нам пишуть, визначаємо, як змінилося співвідношення негативного й позитивного фідбеку.
  3. Аналіз текстових фідбеків за допомогою AI. Ми завантажуємо всі негативні коментарі та порівнюємо їх з попереднім переліком можливих проблем, дивимося, які проблеми ми вирішили, а які нові з’явилися.
  4. «Читати» фідбек треба правильно. Ми не сприймаємо фідбек буквально, а намагаємося виявити реальні проблеми. Наприклад, абстрактні відгуки на кшталт «от якби ви додали {назва фічі} ...» ми не беремо до уваги, натомість намагаємося розгледіти, чи є тут проблема, яка проблема, коли саме вона виникає, як часто, чи ми вже розв’язуємо цю проблему, але користувач не знайшов рішення. Це дає нам змогу виокремлювати факти, з якими можна працювати.

📕 The Mom Test by Rob Fitzpatrick. Цю книгу варто мати під рукою продакт-менеджерам, дизайнерам інтерфейсів і всім, хто розвиває продукт. Видання невелике, але фундаментальне. Воно дає змогу краще розібратися в потребах користувачів, і, як наслідок, — проєктувати функції, що будуть корисними і юзерам, і бізнесу.

Як фідбек посприяв важливим змінам

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

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

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

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

  • конверсія в збереження рослини зросла з 41% до 51%;
  • кількість позитивних відгуків зросла з 71.8% до 82.9%.

Що далі

Наразі ми працюємо над кількома напрямками, які ще більше удосконалять нашу систему.

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

Takeaway note

Щоб фідбек перетворювався на інсайт, він має бути частиною системи Customer Satisfaction: з правильними, уніфікованими точками входу, аналітикою, структурованим флоу. Постійні тести, відстеження метрик та комплексний погляд на питання допомагає робити продукт кращим та досягати першості в ніші.

👍ПодобаєтьсяСподобалось12
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Я не бачу в тексті жодного речення на кшталт «Ми почали орієнтуватися на іншу аудиторію» або «Ми зробили висновки та змінили патерн використання продукту з А на Б». Натомість я бачу концентрацію на метриках та KPI. Недолік такого підходу в тому, що цінність продукта для користувача не сильно змінюється. Це косметичне покращення, а не глобальне.

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

Підписатись на коментарі