RozetkaPay: Заслужити довіру при першій покупці

RozetkaPay — платіжний сервіс-провайдер екосистеми маркетплейсу ROZETKA. Кнопка “Купити з RozetkaPay” дозволяє покупцям оформлювати замовлення на сайтах продавців, використовуючи свій акаунт Rozetka, щоб швидко завершити покупку зі збереженими даними доставки й оплати.

Ключова бізнес-метрика: конверсія відкритого чекауту в покупку. Замовник припускав, що низька конверсія може бути пов’язана з когнітивним дисонансом: покупці на незнайомому сайті не розуміли, чому в них просять номер телефону і до чого тут Rozetka.

Ми поєднали desk research, best-practice benchmarking, конкурентний патерн-аналіз, usability-аудит, глибинні інтерв'ю та модероване usability-тестування, щоб зрозуміти, де саме в чекауті руйнується довіра.

Дослідження показало, що авторизація — лише частина проблеми. Користувачі також не розуміли, що таке RozetkaPay, стикалися з надлишком інформації одразу і мали обмежений контроль над своїми збереженими даними доставки.

Ці знахідки сформували три ключові напрямки рішень: знизити бар’єр для першої покупки, спростити чекаут-флоу та дати користувачам більше контролю над власними даними.

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

Головна проблема, позначена ще на kick-off, — відвал на етапі SMS OTP авторизації. Guest checkout є альтернативним шляхом для покупців, які роблять першу покупку, замість того, щоб змушувати всіх проходити авторизацію за номером телефону перед завершенням покупки.

Guest checkout не був галузевим стандартом, але вже був перевіреним патерном серед головних гравців ринку — за даними нашого конкурентного аналізу та best-practice дослідження.

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

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

Робота над guest checkout привела мене до знахідки з аудиту основного чекауту, який робив колега, — порушення закону Гіка. Логіка чекауту сама по собі була вибудувана правильно — реальна проблема була в порушеній ієрархії. Не було поступового розкриття інформації, не було проведення користувача через процес крок за кроком. Власне, рекомендація аудиту — побудувати флоу навколо поступового розкриття з видимим статусом на кожному кроці, щоб знизити когнітивне навантаження — це саме той напрямок, який я обрала для guest checkout.

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

Кабінетне дослідження й аналіз патернів конкурентів підтвердили, чому це важливо: кожен платіжний сервіс, який ми розглядали, дозволяє користувачам самим керувати збереженими адресами й картками — перемикатися між ними, додавати нові, видаляти старі. RozetkaPay — ні. Зробити це керування видимим і доступним, із можливістю перемикати адреси доставки й додавати нові, було не «додатковою опцією», а базовою річчю, якої нам бракувало.

Usability-аудит уже виявив цю проблему в основному чекауті. Під час usability-тестування нових проблем у цьому сценарії не виявили, але інтерв’ю дали важливі додаткові інсайти: респонденти розповідали про випадки, коли замовлення відправляли не за тією адресою, оскільки вони не перевіряли дані, виставлені за замовчуванням. Також вони самостійно згадували про потребу в мапі для вибору точки видачі замість пошуку за адресою. Поступове розкриття (рішення №2) частково відповідає на цю проблему: покупець проходить чекаут крок за кроком і має більше можливостей перевірити свої дані, замість того щоб швидко прогорнути весь екран.