Страница оплаты на сайте клиента — что-то среднее между корзиной и процессом чекаута. Предыдущая версия в целом устраивала, однако был потенциал для улучшений. Его запланировали реализовать одновременно с переездом сайта на последнюю версию Angular и новую дизайн-систему.
Какие задачи запланировали изначально:
- создать единую страницу оплаты, на которую отправляем пользователя из разных мест интерфейса,
- показать полную информацию о цене и содержимом покупки,
- добавить возможность редактировать покупку на странице оплаты,
- упростить использование бонусов,улучшить навигацию,
- подключить iframe для оплаты.
Больше информации о покупке
Мы уже показывали итоговую сумму и список покупок в предыдущей версии. Однако добавили дополнительную информацию, чтобы снизить количество ошибочных оплат и показать всё самое важное. Например, после предварительного анализа вместе с названием прошивки стали указывать к какой марке, модели и ЭБУ она относится.
Редактирование покупки
Редактирование списка покупок изначально выглядело хорошей идеей.
Начали проектировать и засомневались. Поняли, что простой кнопки «Удалить» не хватит. Нужно: состояние страницы, когда все элементы списка удалены, удаление нескольких элементов одновременно и очистка списка полностью. Выглядело трудозатратно.
Идея возникла из жалоб пользователей на невозможность удалить покупку. После более детальной проверки обнаружили, что таких ситуаций очень мало.
С учетом низкой распространнности проблемы и ограниченного бюджета от идеи отказались.
Оплата бонусами
Включили оплату покупки бонусами по умолчанию, чтобы пользователи не забывали об этой возможности. Для списания подставляем максимально возможное количество бонусов.
Пошаговый сценарий
Разделили страницу оплаты на два шага. На первом — содержимое покупки, использование бонусов и выбор способа оплаты, а на втором — сама оплата.
Добавили на втором шаге возможность сменить способ оплаты. Когда проводили бенчмарк, отметили, что такая возможность есть не у многих. Большинство, когда пользователь дошел до оплаты, максимальное внимание концентрируют на форме ввода реквизитов. Однако логика и здравый смысл подсказывают, что пользователь мог ошибиться на предыдущем уровне, на карте недостаточно денег и т.д. В таком случае получаем тупиковый сценарий без возможности вернуться на предыдущий шаг.
При компоновке страницы пробовали разные решения: вынести сумму и список покупок в сайдбар или, наоборот, объединить все в одной вертикальной форме.
Выбрали вертикальную форму без сайдбара, потому что в блоке с суммой и списком покупок может быть разный контент в зависимости от сценария: одна сумма, сумма с применением скидки, список покупок из нескольких элементов с большим количеством информации по каждому.
Из опасений. Раньше на мобильных кнопка перехода к оплате была всегда на виду. В новой версии кнопка оказалась вне зоны первого экрана до скролла. Возник вопрос: «Вдруг этим решением мы уроним конверсию на мобильных?»
Рискнули и сделали. Времени и бюджета на тестирование вариантов не было. После релиза проанализировали данные. Опасения не подтвердились: пользователи скроллят страницу и проблем с переходом к оплате нет.
Также сразу добавили другие небольшие изменения:
- сократили названия некоторых пунктов оплаты,
- начали разбивать сумму по разрядам для удобного считывания,
- отменили блокировку бонусов на час при ошибочной оплате, но для крайних случаев добавили предупреждение.
Внедрение iframe
Идея добавить оплату в iframe пришла от клиента. Он был против перехода пользователей на сайт платежной системы.
Предварительно мы поискали исследования и кейсы с переходом на оплату в iframe. Не нашли ничего полезного. Поспрашивали у коллег из сферы — пусто. Это было единственное решение, не основанное на данных.
С технической стороны все выглядело не очень трудозатратно, но в процессе реализации мы столкнулись со сложностями:
- документация используемой платежной системы была неполной и устаревшей,
- техническая поддержка платежной системы не могла полноценно ответить на вопросы по реализации (нам помогло общение непосредственно с разработчиками, на которых вышли через руководителя офиса),
- при оплате через QIWI и ЮMoney использование iframe невозможно, только для банковских карт,
- ограниченные возможности для кастомизации шаблонов iframe.
В итоге оплату в iframe мы сделали только для банковских карт. Однако в релиз она не ушла. Платежная система в этот момент начала переход к новым шаблонам и стандартнам реализации. Решили подождать изменений с их стороны, чтобы не увеличивать трудозатраты и снизить вероятность ошибок при переходе.
Итоги
Обновление страницы оплаты — изменение с высоким уровнем риска. Даже небольшое снижение конверсии повлияло бы на выручку клиента. Поэтому мы много времени потратили на анализ и проектирование.
В результате улучшили метрики завершения оплаты, сократили количество ошибок при оплате, увеличили конверсию в оплату среди новых пользователей (среди лояльных статистически значимого изменения нет). Внедрение iframe зависло в ожидании изменений со стороны платежной системы, результатами поделимся позже.