Щоб дізнатися на ранній стадії продукту, яка фіча принесе більше цінності, не треба «ворожити на кавовій гущі». Продакт формує гіпотези, а потім перевіряє їх за допомогою прототипів. Попросили Єгора Кургузова, Head of Product у Hurma, та спікера курсів UX Matters та Product Unit, поділитися досвідом, як продактe працювати з дизайном.
Привіт, мене звуть Єгор. За 7 років у продуктовому менеджменті я встиг попрацювати в компаніях різного напряму: від Concepter: hardware&consumer electronics з продажами IT-девайсів по всьому світу до випуску софту для автомобілів із тривалим циклом розробки та валідації гіпотез на драйверах у CloudMade.
Зараз ми з командою Hurma розвиваємо розумну HRM-систему, а в Custle працюємо над створенням маркетплейсу для індустрії кастингу акторів і моделей.
Гіпотези та MVP
Створення нового продукту або впровадження нової функціональності починається з виявлення проблем і запитів користувачів. Далі ми висуваємо гіпотези: навіщо треба щось запровадити, прибрати поміняти. Наприклад, щоб збільшити якісь показники, покращити вибрані метрики, зробити процес зручнішим.
Для перевірки цих гіпотез існує купа різних опцій. Якщо ми говоримо про якісь user-facing речі, їх можна перевіряти прототипами, виявляти, чи справді гіпотеза спрацювала. Такі прототипи менеджер може робити разом із дизайнером.
За допомогою прототипів можна провалідувати чи, навпаки, інвалідувати якусь гіпотезу. І чим раніше вдалося перевірити гіпотезу, тим дешевше це обійдеться компанії.
Minimum Viable Product — це сукупність цінностей, які ми доставляємо користувачам. Ерік Райс, автор книги Lean Startup, називає MVP таку версію продукту, яка дозволяє зібрати максимальну кількість корисних відомостей із мінімальними зусиллями.
MVP має відповідати двом основним критеріям:
- Мати цінність для користувачів. Дізнатися про реальні потреби людей нам допомагає правильна робота з гіпотезами.
- Генерувати фідбек. Для цього потрібно максимально швидко деліверити MVP на ринок.
На етапі Minimum Viable Product ще не стоїть питання про технічну досконалість чи підтримку мільйонів користувачів: ми фокусуємося на цінності та на фідбеку.
Зазвичай, менеджер чи бізнес-аналітик знаходять і формують різні гіпотези самостійно, а потім ці припущення трансформуються в експерименти, які вирішує команда. Експерименти можуть бути різні: щось намалював дизайнер на папері, і ми це перевірили. А щось потрібно допрототипувати до детальнішого рівня, навіть із кодом, і зарелізити кудись для отримання даних.
Як відсіювати гіпотези
Дуже добре залучати команду на етапі створення припущень, бо кожен учасник має свій погляд. Розробники можуть підказати, наприклад, що із запропонованого не можна реалізувати через технічні обмеження або для перевірки знадобиться занадто багато часу, а команда QA допоможе побачити недоліки в логіці.
Командне обговорення і критика допомагають розставити пріоритети, але все ж таки основний інструмент відсіювання — це валідація на реальних користувачах. Найшвидший і найпростіший спосіб — інтерв’ю, експерименти з трафіком, зміна позиціонування в рекламі. На більш зрілій стадії продукту гіпотези валідують прототипами: показують людям, тестують, вивчають реакцію.
Підхід до формування MVP через різні експерименти і постійне відсіювання гіпотез, дозволяє вибирати правильний напрямок і не втрачати гроші.
На малюнку ліворуч — продукт довго робили, зарелізили — і виявилося, що він не затребуваний. Припустимо, компанія щось робила 5 років, вкладаючи щороку по мільйону доларів у розробку, а через 5 років дізналася, що продукт нікому не потрібен, такої проблеми люди не мають, або вирішують її чимось іншим.
Більш ефективний підхід на малюнку праворуч: ми діємо різного роду експериментами, ітераціями. Це дозволяє без високих капіталовкладень перевіряти гіпотези, відкочуватися назад, якщо все погано і рухатись далі, коли все добре. На малюнку видно, що компанія могла вже п’ять разів запивотити продукт і, в результаті зробити те, що дійсно потрібно людям (прим. ред. PIVOT — зміна курсу руху стартапу з метою протестувати новий напрямок розвитку).
Тому наше завдання рухатися маленькими кроками, короткими ітераціями.
Насамперед, перевіряємо найбільш ризиковані та впливові гіпотези.
Умовний ризик — наскільки велика міра невизначеності, яка без належної перевірки може поховати продукт.
Impact — сила впливу на користувачів.
Пріоритезувати різні припущення мені зручно за допомогою матриці: можна швидко розкласти гіпотези і побачити, куди спрямовувати зусилля саме зараз.
Матриці для пріоритизації гіпотез
Як це працює. Ми розташовуємо всі стікери з бізнес-моделі (або з іншого джерела) у відповідному квадранті. Як правило, потрібно в першу чергу перевіряти припущення з правих верхніх квадрантів.
У матриці зліва — це будуть найвпливовіші та найнебезпечніші гіпотези з високим ступенем невизначеності. Можна замість невизначеності на горизонтальній шкалі підставити «рівні умовного ризику», тому що чим вища невизначеність, тим і вищий ризик.
На малюнку справа, горизонтальна вісь може означати не лише простоту, а й час проведення експерименту.
В ідеалі, стікери з гіпотезами повинні мігрувати по матриці, якщо процес роботи з гіпотезами побудований у більш-менш стабільному вигляді.
Для наочності наведу приклад гіпотези з low uncertainty: Колись ми консультували продукт у близькодержавному секторі. І там був низький ступінь невизначеності того, що ринок корумпований — ми точно знали про бюрократію та корупцію, це був просто факт.
Знаючи про це обмеження, ми додавали більше сек’юрності у продукт: робили подвійні та потрійні верифікації. А в показниках «високої невизначеності» у нас був інший фактор: наскільки продукт потрібен споживачам і чи вдасться перевести в онлайн офлайнову сферу. Щоб знизити невизначеність, ми дробили гіпотезу на конкретні таргет-сегменти, географії, і вже після цього перевіряли їх one by one.
Assumptions validation flow
Перевірка та валідація гіпотез зводиться до лінійного процесу. Перші два пункти — input, і на місці бізнес-моделі може бути майже будь-який продуктовий артефакт: Value Prop, Customer Journey Map, просто сирі інсайти з інтерв’ю, все залежить від стадії життя продукту.
І якщо зібрати весь флоу в покрокову інструкцію, ми отримаємо щось таке. Добре працює для внутрішньої innovation lab, коли є постійна мета опрацьовувати досить багато нових бізнес-моделей.
- Define biz models.
- Evaluate biz models.
- Prioritize the hypotheses — теж input, який виллється в гіпотези, сформульовані та розставлені у порядку пріоритетності.
- Build an action plan із розписаними експериментами для перевірки наших гіпотез. Форма action plan може бути будь-якою. Я закидаю все в Miro і після появи моєї матриці, стрілочками з’єдную інші картки, які і являтимуть експерименти.
- Go out of the building. Наше завдання тут — отримати реальні дані ззовні, а для цього потрібно провести аналітику або заделіверити щось на ринок. Наприклад, скрипт інтерв’ю — заделівірили питання на ринок і отримали у відповідь реальний досвід та кейси для майбутньої розробки. Або заделівірили клікабельний прототип малої групи користувачів: взяли 10 early adopters, які люблять і підтримують нас, показали їм як виглядає apk, люди поклікали — і стало зрозуміло, що їхні проблеми не вирішуються.
Повертаємося з отриманими інсайтами, переробляємо і знову виходимо. Сіль у тому, що ми не починаємо розробку, доки не підкріпимо її реальними даними. - Evaluate the results. Будь-який експеримент передбачає якийсь результат. Якщо говорити про валідацію позиціонування (наприклад, з різними банерами на Facebook), то success metric тут — ціна імейлу. Ставимо собі певний поріг очікування: наприклад, не більше 2 доларів за імейл і далі дивимось. Перший варіант банера — провалив очікування, вийшло 5-6 доларів за імейл, а другий і третій — перевершили: вартість вийшла меншою за 2 долари. Тут, звичайно, важлива репрезентативність вибірки та охоплення потрібної кількості людей для перевірки.
Прототипи: як research перетікає у дизайн
Модель Double Diamond
Гіпотези є завжди, їх потрібно валідувати, просто набір гіпотез може трансформуватися і видозмінюватися. Ми розширюємо цей набір на рівні research: збираємо на інтерв’ю можливі налаштування, виявляємо проблеми, які могли б покрити. Далі звужуємося до конкретної потреби або pain point, який ми і вирішуватимемо.
На другому «діаманті» ми знову розширюємося до безлічі можливих рішень і на стадії валідації відсіюємо невідповідні опції. Фінальним етапом для розробки, в більшості випадків, йдуть usability тести, які вносять фінальні корективи в майбутню фічу. Але це все нескінченно, тому що навіть після релізу ми продовжуємо валідувати фічу та зменшувати ступінь невизначеності, тільки тепер уже з метриками та аналітикою.
У Custle ми взяли ринок кастингу, провели аналіз та вирішили, що можна зробити окремі SaaS для акторів та для директорів, або маркетплейс для всіх, або навіть точковий продукт для проведення самопроб. Тобто врахували величезний спектр різних можливих варіацій. Але після десятків експериментів і різноманітних досліджень ми звузилися до маркетплейсу. Причому SaaS — як і раніше наш план Б, і ми розглядаємо його як можливість для півоту, якщо інвалідуємо ключові гіпотези маркетплейсу після публічного запуску.
Валідація гіпотез лише на рівні дизайну відбувається по-різному. Візьмемо банальний приклад — колірні схеми:
- зробили 5 варіантів поєднань кольорів;
- запустили А/В тест із позиціонуванням та використанням фірмового стилю;
- побачили, що, скажімо, червоний колір для ринку працює краще.
Ця валідація дозволила нам звузитися далі. І на фінальному звуженні від solution до подальших кроків далі може бути вже ринок, якщо ми говоримо про фазу solution market fit. Ось на цьому рівні ми вже опрацьовуємо юзабіліті-тести і тут йдеться про досить пропрацьовані прототипи. Зі зростанням зрілості продукту і гіпотез підвищуватиметься і ступінь деталізації прототипів.
Sketch
На ранньому етапі можна просто намалювати щось на папері. Якщо говорити саме про роботу менеджера з дизайном та продуктовою командою в цілому, раннє тестування дає результат вже на початковому етапі. Це якраз найважливіше в lean: ми відразу (a.k.a. «дуже швидко») щось будуємо, вимірюємо та вчимося.
Мені дуже подобається в цьому плані кейс Яндекс.Таксі. Коли вони робили навігатор у своїй програмі, вони валідували user experience навігаційних інструкцій з допомогою паперу.
Як це відбувалося: продакт менеджер сідав поряд із водієм і вони їхали маршрутом. У менеджера заздалегідь були заготовлені невеликі паперові банерки та мапа навігатора з вимкненими підказками.
Телефон лежить на панелі, там відображається карта, а продакт під час поїздки підкладає конкретні банерки та озвучує голосом конкретні підказки.
Завдяки цьому вони дізналися на якій дистанції і коли повідомляти про поворот, як повинен виглядати дизайн повороту, я якому місця інтерфейсу розташовувати цей елемент і т. д. Це приклад прототипу дуже низької деталізації (low-fidelity), який дозволяє провалідувати досвід користувачів.
Отримані на ранньому етапі інсайти компанія використовує далі для створення більш зрілих прототипів у вигляді інтерфейсів.
Wireframe
Це фактично макет без дизайну: одні кружечки, квадрати та текст. Для wireframe — чим простіше, тим краще. Саме так вчать прототипувати у топових бізнес-школах. Дизайнер може подивитися на wireframe і прикинути: на сторінці повинні бути такі елементи, зрозуміло. А як їх відобразити, дизайнер визначить сам.
Вайрфрейми вважаються інструментами роботи продакта. Але бувають команди, де wireframe створюють дизайнери. Іноді команда в принципі не приймає такого рівня прототипу, тому що він здається людям незрозумілим, несхожим на «нормальний» дизайн.
Але тут все залежить від мети і того, як менеджер доніс до команди, що завдяки таким експериментам на ранній стадії у нас з’являються знання, щоб рухатись у потрібному напрямку.
Mockup та Prototype
На стадії growth stage, коли продукт дуже зрілий і у нас вже мільйон користувачів — валідація проходитиме з великою кількістю лімітів, затверджень зі стейкхолдерами (скоріше за все, але якщо це не так — моя повага), тому прототипи будуть більш детальними.
Mockup виглядає як реальний інтерфейс, лише неклікабельний.
Prototype — проєктують у додатку типу InVision, щоб можна було поклікати та проаналізувати повноцінну поведінку користувачів.
У прототипах початкових рівнів немає сенсу відображати весь продукт, і навіть MVP продукту. У зрілих прототипах ми намагаємось показати реальний продукт.
Наприклад, коли ми переходимо на рівень product market fit і намагаємось зарелізити продукт у App Store. Звичайно, хочеться швидше зробити зрілий продукт, довести до фіналу, щоб усі його завантажували, але…
Щоб перевірити гіпотези, не потрібно з фанатичним перфекціонізмом розвивати продукт до максимального стану. Наше завдання — якнайшвидше набути знань, отримати дані. Тому на місці майбутніх красивих динамічних елементів зараз можна поставити заглушку.
За допомогою прототипів високої деталізації ми можемо «замокати», зімітувати якісь речі. Можна не створювати менш важливі сторінки. Наприклад, у додатку для вивчення дорожніх правил сторінка типу My profile не завжди важлива, і нею можна знехтувати.
Ми можемо постійно відкладати перевірку фінальної гіпотези, тому що вона впирається у розробку і потрібно витратити ще два місяці. Обговоріть із командою, можливо це все можна «замокати», або земулювати поведінку користувачів за рахунок якоїсь бібліотеки Google (або чогось іншого, розробники знають).
Перевикористовуйте речі. Навіть у рамках однієї компанії часто є кілька продуктів, припустимо, все для e-commerce. Якщо ми придумали новий маркетплейс для конкретного ринку — перепродавати одноразовий посуд, щоб перевірити нашу гіпотезу, можна взяти підпродукти або компоненти з інших команд. Вони, напевно, вже робили щось схоже і у них є якісь building blocks, API, дата-сети, тому підключайте до прототипування і свою команду, і комунікуйте свої цілі назовні.
Прототипи високої деталізації створюються за допомогою спеціальних інструментів. Менеджеру для цього не потрібно ставати дизайнером або вчитися кодити. У програмах типу Balsamiq або Axure можна самостійно накидати блок-схеми і фрагменти інтерфейсу, а потім передати їх дизайнеру для опрацювання.
Можна також показати такий прототип користувачам, щоб вони пройшли user flow, спробували знайти щось в інтерфейсі. Для такого дослідження може бути досить базового вигляду: квадратики і текст. Ви зрозумієте, орієнтується людина в намальованому інтерфейсі або нічого не розуміє, плутається в кривому флоу і впирається в логічні тупики.
Майже всі прототипування зводяться до вивчення user experience. Тому завжди апелюйте до реальних даних. Не використовуйте прототипи, щоб просто віддати їх дизайнеру як ТЗ. Робіть їх, щоб отримати знання про користувачів. Будь-яка ітерація прототипів повинна давати вам якесь знання, а далі ви адаптуєте свій роадмап/беклог/вимоги (підкреслити потрібне) згідно з новими даними.
Завжди перевіряйте, міряйте, вивчайте досвід реальних людей. Отримані інсайти використовуйте для покращення взаємодії та створення такого продукту, який полюблять користувачі.
І не забувайте працювати із гіпотезами! Поки ви робите це усвідомлено — ви не заблукаєте у всіх цих множинних валідаціях та експериментах.