Genesis Tech
2022
User Research з нуля: як допомогла побудувати Research-процес у продуктовій команді
Як я допомогла побудувати user research з нуля для застосунку сканування документів у Genesis Tech
Overview
Трошки контексту
У вересні 2022 року я доєдналась до команди Retention Hack Team (RHT) у ролі UX - ресерчерки.
RHT була внутрішньою консалтинговою командою для продуктів Genesis Tech.
На практиці моя роль включала набагато більше, ніж "провести кілька інтерв'ю".
Ми приходили до продуктових команд, дивились на дані, шукали точки росту, придумували й тестували гіпотези — коротше, намагались зрозуміти, що можна зробити з продуктом, щоб він працював краще і приносив більше доходу.
У кожного в команді був свій напрямок, за який він відповідав.
Тож неважко здогадатись, яка зона відповідальності була у мене :)
The Starting Point
З чого все почалось?
Перший продукт, з яким ми почали працювати — застосунок для сканування документів.
Кількісна база в команди була просто супер: дані про використання зібрані, структуровані, все чітко. А от якісного дослідження не було взагалі. Ніхто в команді за це не відповідав.
Тобто команда добре бачила ЩО роблять користувачі. А от ЧОМУ — ні :)
Хто взагалі наші користувачі?
Чому не продовжують підписку?
Що їх бісить у продукті?
Які задачі вони намагаються вирішити?
Чого їм не вистачає?
Без відповідей на ці питання команда, по суті, будувала експерименти наосліп.
І тут постало питання: окей, а як доповнити те, що ми вже знали з даних, голосом самих користувачів?
Approach
01 / Спочатку потрібно було зрозуміти, чого ми насправді не знаємо
Найперше, що мене трошки навіть лякало — наскільки різносторонньою була моя роль в межах цього продукту. Не було встановленого процесу, не було шаблону, якого можна було б просто дотримуватися. Необхідно було будувати його самостійно, опираючись на свої знання та досвід.
І почати варто було не з методів чи інтерв'ю, а з того, щоб чесно розібратись: що команда знає про своїх користувачів напевно, а що лише вважає правдою.
Тому перш ніж іти до користувачів, я провела експертні інтерв'ю з людьми, які вже давно працювали з продуктом.
Мені було важливо розділити:
що ми знаємо → що припускаємо → що потрібно перевірити.
Це дало мені фокус: куди саме варто копати в розмовах з реальними користувачами, а що можна закрити й без них.
Process
02 / Далі потрібно було побудувати сам процес
На той момент у продукті не було якогось готового процесу якісних досліджень.
Тому я не хотіла, щоб усе звелося до формату
провели кілька інтерв'ю → зробили презентацію → пішли далі
Хотілося побудувати нормальний процес, який реально працюватиме для команди.
1)Починаємо зі стратегії
Розуміння того, що ми знаємо, а що ні, потрібно було перетворити на конкретні дії. Я перетворила бізнесові та продуктові питання на структурований research plan.
Аби у всіх було розуміння, що саме досліджуємо, якими методами, кого рекрутуємо і в які терміни вкладаємось.
Сформувала основне дослідницьке питання:
Як зробити продукт настільки привабливим для для користувача, щоб він був готовий оформити або продовжити платну підписку?
Та розклала його на три цілі: зрозуміти, хто наші користувачі, зрозуміти, в чому для них цінність, і знайти проблеми та бар'єри, які заважають цю цінність отримати.
2)Далі - інтерв’ю з користувачами
Разом з продакт менеджером, я займалась рекрутингом і проводила глибинні інтерв'ю з користувачами з різних сегментів та англомовних ринків.
Ми спеціально дивились на різні групи:
Premium subscribers — чому вони готові платити?
Free users who didn't convert — що зупинило їх від покупки?
Churned users — чому вони пішли?
Я особисто провела 5 інтерв'ю, поступово підключаючи й команду.
Крім того, ми паралельно провели перше велике опитування користувачів — 1 800+ респондентів.
Разом із продуктовою командою ми спроєктували анкету, щоб перевірити ключові припущення на більшій вибірці та краще зрозуміти поведінку, потреби й очікування користувачів.
3)Інсайти
Після інтерв'ю треба було транскрибувати всі ці розмови й виділити ключові інсайти. Я аналізувала їх, шукала патерни й структурувала у зрозумілі для всіх знахідки. І все це робилось ручками — боже бережи AI-шку, яка тепер спрощує і пришвидшує всі ці процеси.
Всі ключові знахідки я презентувала продуктовій команді.
Крім того, створила структуровану research-базу в Dovetail, де зберігалися інтерв'ю, нотатки, теги та інсайти.
Бо, Research не має жити десь у ноутбуці ресерчера, якщо ми вже витратили час на те, щоб щось дізнатися про користувачів, цим знанням має бути легко скористатися і через місяць, і через пів року
Handoff
03 / Research має працювати і без тебе
Для мене було важливо, щоб всі знахідки не пішли в “стіл” на потім, як це буває в деяких компаніях.
Тому, працюючи разом із PM, аналітиком і продуктовою командою, ми генерували гіпотези для експериментів, базуючись на знахідках з дослідження.
Ми пов'язували user insights із тим, що вже показували аналітика та бізнес-дані, і разом формували продуктові гіпотези, які команда могла брати в експерименти й перевіряти вже на рівні продукту.
Так поступово user perspective ставала ще однією частиною продуктового процесу — поруч із аналітикою та бізнес-даними.
Але для мене було важливо не тільки те, як Research працює в команді, а й те, хто зможе його продовжити без мене.
Моєю метою не було стати постійною дослідницею команди.
З самого початку я знала: процес має працювати без мене. Тож я свідомо будувала перехід у три етапи :
Я веду, команда долучається
Я провела перші інтерв'ю й залучила PM та інших членів команди до процесу. Замість того, щоб просто ділитись фінальними результатами, я запрошувала їх у сам процес дослідження — щоб вони бачили, як інтерв'ю плануються, проводяться й аналізуються.
Команда веде, я підтримую
Члени команди почали самостійно проводити інтерв'ю. Я допомагала з підготовкою, давала фідбек і залишалась доступною, коли їм була потрібна підтримка.
Команда володіє процесом
До завершення проєкту один з членів команди вже самостійно рекрутував людей, проводив інтерв'ю й вносив усе в базу — без мене.
Lessons
04 / Що з цього вийшло
На початку в команди були хороші кількісні дані, але не було системного способу зрозуміти, чому користувачі поводяться саме так.
Поступово з'явилися:
побудований qualitative research процес;
структурована база дослідницьких даних та інсайтів;
досвід проведення інтерв'ю всередині команди;
спільніше розуміння користувачів;
розуміння як робити Research далі
Але для мене найбільшим результатом був не звіт з дослідження. А те, що я зробила user research чимось, чим команда могла продовжувати користуватись без мене.
