Одна сторінка – дві задачі
Plan Page одночасно допомагає працювати з маршрутом і продає доступ до повної подорожі.
Користувач отримує один відкритий день. Щоб побачити решту, потрібно розблокувати подорож. На цій сторінці він має зрозуміти якість плану, можливості редагування та умови покупки.
Я почала з перевірки: що саме заважає зрозуміти план і його цінність до оплати?
Як я досліджувала продукт
Провела три проходження продакшну: семиденні подорожі до Мілана й Фано та триденну до Парижа – на десктопі й мобільному. Окремо перевірила оплату, генерацію закритих днів, додавання готелю й оновлення бюджету.
Паралельно проаналізувала покупки, проходження туру, взаємодії з AI та повернення користувачів. Перевіряла висновки з розробником: частина проблем залежала від логіки генерації, частина – від того, як інтерфейс її пояснював.
Спостереження зі старих макетів також перевірила в продакшні. Наприклад, проблему з даними іншого міста не вдалося відтворити – її виключила з фінального списку.
Як метрики вплинули на рішення
Рішення про покупку приймають за кілька хвилин
- Дані
- За 90 днів зафіксовано 13 покупців. Медіанний час до покупки – 250 секунд. В окремій вибірці ретеншну з 325 користувачів на першому тижні поверталися 6,6%.
- Що перевірила
- На сторінці було п’ять назв однієї покупки. Погода, карта й редагування стояли серед платних можливостей, хоча тур називав їх безкоштовними. Безлімітний AI після оплати не був пояснений.
- Яке рішення прийняла
- Першим пріоритетом визначила зрозумілу пропозицію: єдина назва покупки, чітка межа між безкоштовним і платним та пояснення того, що відкриється після оплати.
ПриміткаЦифри не доводять причину відмов від покупки, але разом з аудитом стали аргументом зосередитися на першому знайомстві з планом.
Низька цифра використання AI потребувала перевірки
- Дані
- AI Replace мав лише 3 зафіксовані взаємодії серед 353 користувачів без покупки – близько 1%.
- Що перевірила
- Після заміни текстової кнопки іконкою дія перестала коректно відображатися в наявному трекінгу. Цифра не дозволяла оцінити реальне використання функції.
- Яке рішення прийняла
- Не використала низький показник як аргумент прибрати AI Replace. Запропонувала зробити дію зрозумілішою та відновити її вимірювання.
ПриміткаДля подальшої оцінки важливо бачити весь сценарій: запуск AI → отримання результату → прийняття або скасування зміни.
Тур проходили 28%, але проблема була також у його змісті
- Дані
- Із 318 стартів туру 88 завершили проходження – близько 28%. Медіанна тривалість становила 37 секунд на дев’ять кроків.
- Що перевірила
- Чотири кроки описували можливості, яких не було або які були недоступними в поточному стані. Тур формував очікування, які сторінка не підтверджувала.
- Що запропонувала
- Узгодити підказки з реальними можливостями та станами продукту, а пояснення дій показувати в момент взаємодії. Рекомендації щодо туру винесла за межі погодженого редизайну Plan Page.
ПриміткаЧерез малу кількість покупців я не робила висновку про вплив проходження туру на конверсію.
Спочатку – перевірка якості даних
20 липня змінили одразу кілька частин продукту: реєстрацію, кукі-банер і кнопку редагування. Статистика за 90 днів поєднувала різні версії користувацького шляху.
Я запросила окремі зрізи до й після змін. Також виявила, що наявні події не покривають роботу з таблицею – основним інструментом сторінки. Підготувала список із 7 пріоритетних і 4 додаткових подій.
Пояснити бюджет до розблокування
- Проблема
- У тестовій семиденній подорожі до Мілана до оплати відображалося €386, після – €2 456. Я перерахувала витрати: початкова сума охоплювала лише перший день для двох людей – близько 16% повної оцінки. В інтерфейсі вона виглядала як бюджет усієї подорожі. Розробник підтвердив: дні 2–7 генеруються лише після оплати.
- Що запропонувала
- Позначати початкову суму як бюджет відкритого дня. Після оплати показувати стан генерації, а загальний бюджет – після завершення розрахунку.
- Що це має змінити
- Користувач розумітиме, які витрати вже враховані й чому сума оновлюється. Різниця між частковою та повною оцінкою стане поясненою частиною сценарію.
Зберегти таблицю й покращити навігацію
- Проблема
- Дні мали різну поведінку: перший відкритий, другий – розмитий тизер, наступні – замкнені. Повторювані блоки ускладнювали перегляд довгої подорожі, а карта не показувала всі зупинки.
- Що дослідила
- Порівняла конкурентів за 15 напрямками та розглянула патерни Airtable, Notion і Linear. Таблиця виявилася сильною основою для редагування маршруту, яку варто зберегти.
- Що запропонувала
- Одну таблицю з групуванням за днями та зв’язком між рядком і маркером на карті. Зберегти перетягування зупинок, відрізки маршруту й погоду, а повторювані елементи скоротити.
- Що це має змінити
- Користувач зможе швидше переходити між днями та співвідносити послідовність зупинок із маршрутом на карті.
Зробити покупку й стан після неї зрозумілими
- Проблема
- Інтерфейс змішував покупку подорожі та кредитів. За замовчуванням пропонувався пакет за $9.99 замість однієї подорожі за $3.99. Після розблокування лічильник кредитів міг оновитися лише після перезавантаження, а генерація решти днів не мала достатнього пояснення.
- Що запропонувала
- Для одиничної покупки пояснювати пропозицію через подорож, для пакета – через кредити. Узгодити назви й опис доступу, показати генерацію та своєчасно оновлювати залишок кредитів. Підготувала матрицю з 11 станів, щоб поведінку сторінки можна було узгодити до деталізації макетів.
- Що це має змінити
- Користувач бачитиме, що купує, чи завершилась оплата і коли повний план буде готовий.
Прототип
Від готового трипу до нового
Старт – уже готовий трип до Парижа, звідти через ✦ відкривається бічна панель і створюється трип до Мілана. Екрани створення дорисовані під редизайн, Plan Page – з редизайну. Прототип гортається сам, а в режимі «Спробувати самій» його можна проклікати.
- Паріж · готовий трип
- Куди
- Дати
- Створити трип
- Генерація дня 1
- День 1 безкоштовно
- Оплата
- Генерація днів 2–7
- Увесь трип
Як визначила обсяг редизайну
У межах домовлених 12–15 годин пріоритет отримали зміни в поясненнях, порядку елементів і видимості дій:
- частковий бюджет та його оновлення;
- умови розблокування;
- стани після оплати;
- навігація між днями;
- зрозумілі дії редагування.
AI з порівнянням змін і скасуванням, рекомендації для вільних проміжків та коментарі до зупинок залишила для наступних ітерацій.
Як перевірити зміни
Перед впровадженням потрібно узгодити події та зафіксувати базові показники. Для оцінки редизайну запропонувала відстежувати:
| Що перевіряємо | Що вимірюємо |
|---|---|
| Зрозумілість пропозиції | Перегляд плану → відкриття пропозиції → успішна покупка |
| Зручність роботи з маршрутом | Перше редагування, переходи між днями, взаємодії з картою |
| Використання AI | Запуск → результат → прийняття або скасування |
| Стан після оплати | Завершення генерації та коректне оновлення бюджету |
Окремо на перевірці сценаріїв варто з’ясувати, чи розуміють люди, що входить у бюджет і що саме відкривається після покупки.
Результат і висновки
Дискавері перетворило загальний запит «спростити Plan Page» на конкретний план редизайну:
- 30 проблем із доказами та рекомендаціями;
- запропонована структура з 7 переміщеннями елементів;
- матриця з 11 станів інтерфейсу;
- 7 пунктів для розробки;
- пріоритети для розширення трекінгу.
Найважливішим для мене було зіставити цифри з тим, що реально відбувається в продукті. Низький показник використання AI виявився ненадійним через трекінг, а різниця бюджету – наслідком генерації після оплати. Ці перевірки змінили і постановку проблем, і запропоновані рішення.
У наступному проєкті я перевіряла б покриття подіями та історію змін продукту ще на початку аналізу – до інтерпретації відсотків.
Наступний етап: узгодити модель покупки й обсяг змін, завершити макети та перевірити ключові сценарії. Вплив редизайну на конверсію й використання плану можна буде оцінити після впровадження.
