Закрытие legacy-формы оплаты

PM of record и Product Designer в 38-недельной миграции со старой формы оплаты, работавшей 15 лет, на новую – в B2C/B2B SaaS-биллинге, силами четырёх команд. Документирование сценариев, биллинговый дизайн-кит и цикл из трёх экспериментов – провал, AA-тест, повтор – при критерии успеха «без потери конверсии».

Контекст

Продукт – подписочный B2C/B2B SaaS-сервис. Отдел биллинга состоял из четырёх команд: процессинг и управление платежами, подписки и офферы, управление лимитами, внешний биллинговый кабинет пользователя.

На момент проекта по закрытию старой формы оплаты, в продукте существовало две формы:

• старая – длинная, с большим количеством данных для отображения и сценарими например для апгрейда/даунгрейда подписки
• и новая, короткая, которая была создана чтобы заместить старую, но покрывала только один сценарий оплаты

Основная часть платежей проходила по старой. В рамках модернизации системы биллинга было принято решение закрыть старую форму окончательно и перевести всех пользователей на новую форму.

Проблема

Старая форма имела UX-проблемы, из-за которых компания теряла деньги: пользователи могли случайно перезаписать существующую подписку с накопленными лимитами новой подпиской. Новая форма, в свою очередь, не поддерживала основные сценарии оплаты и различные ситуации апгрейда/даунгрейда подписки.

Задача была не просто «сделать красивее», а закрыть функциональный пробел между формами и обеспечить безопасный переход без потери конверсии.

Бизнес-кейс строился на стоимости поддержки и реальном дефекте, а не на приросте выручки. Поэтому успех заранее определили как отсутствие потери конверсии, а не как рост конверсии. Это различие было принципиальным: через длинную форму проходило всего около 3 100 визитов в неделю, и требовать доказанный рост на таком трафике означало бы застопорить миграцию, оправданную совсем другими причинами.

Проект шёл с июня 2024 по март 2025 – 38 недель по плану, силами четырёх команд биллинга.

Моя роль

Я был PM of record на этом проекте и одновременно занимался дизайном. Как PM это значило: информировать стейкхолдеров о статусе, вести еженедельные синки с двумя Product Owner’ами, дизайнером из смежной команды и самой командой, фиксировать прогресс на роудмапе и в других каналах.

Как Product Designer:

• Описал все существующие сценарии оплаты в старой и новой форме – апгрейд, даунгрейд, покупка дополнительных лимитов – впервые собрав их вместе в одну схему
• Разделил зоны ответственности на форме между командами для визуального ориентирования
• Разработал черновик финальной структуры формы и согласовал его со всеми участниками
• Вместе с дизайнером из смежной команды договорился о разделении модулей в Figma – кто что реализует, как передавать компоненты другим командам и как их аппрувить
• Вместе с другим дизайнером, разработали биллинговый дизайн-кит, на основе дизайн системы, с настраиваемыми компонентами (например, отдельные состояния «есть карта» / «нет карты» и.т.д)
• Интегрировал готовые модули смежного дизайнера в общую схему сценариев
• На всех этапах разработки совместно с QA и командами тестировал сценарии вручную по схеме, выписывал и согласовывал правки

Исследование

Исходные данные на момент старта:

• ~3 100 средних посетителей в неделю на длинной форме оплаты (без карт)
• Конверсия Visit → Submit: 61.42%
• Конверсия Visit → Payment + Trial: 53.63%
• Целевой MDE (минимально детектируемый эффект): +2% по каждой метрике

Низкий трафик на длинной форме – это ограничение, которое определило весь дальнейший ход проекта. При ~3 100 визитах в неделю статистически надёжный эксперимент на нижней части воронки медленный и сложный – именно поэтому проект оценивался по паритету, а не по приросту.

Заметка про прогнозы: плановые документы проекта также содержали прогноз примерно в 25 дополнительных платежей в неделю при достижении целей. Это была предпроектная оценка для планирования объёма работ, а не измеренный результат, и нигде в этом кейсе она не заявляется как достижение.

Процесс

1. Документирование сценариев

Первым шагом было собрать все сценарии работы с обеими формами в одну схему. Никто до этого не собирал сценарии обеих форм в одном месте. Крупные кейсы понимались интуитивно, часть нигде не фигурировала. Первым делом задокументировал все сценарии, свёл в схему. Дальше она работала как общий язык между командами – при разграничении зон ответственности, согласовании макетов и ручном тестировании на разных этапах.

Последний утвержденный вариант схемы. Далее все было перенесено в актуальные файлы. А это осталось как рабочий черновик.

2. Дизайн-кит и компонентная архитектура

Параллельно с другим дизайнером договорились о том, как делать публичные компоненты для поставки другим командам. Каждый дизайнер реализовывал свои модули самостоятельно, затем базово проверяли и согласовывали между собой.

Получился биллинговый кит – набор компонентов с настраиваемыми состояниями под разные контексты интеграции.

3. Тестирование дизайна

Тестировали быстро и итеративно – скриншоты состояний в Slack, голосование через эмодзи внутри команды дизайнеров, точечные проверки с sales и customer success. Формат выбран осознанно: нам не нужна была идеальная форма, нам нужна была рабочая замена старой.

4. Разработка и выкатка

Старая форма жила на legacy-стеке – это задавало темп всей разработке. С каждым собранным модулем по макетам на фронте, совместно с QA и командами шли по схеме сценариев вручную и тестировали. На прод выходили постепенно, через эксперименты, особенный акцент был на критичных сценариях.

Эксперименты

Эксперимент 1 – Провал

Первый A/B тест запустили на пользователей, пробующих триальные подписки.

Вариант хорошо привлекал пользователей к форме и увеличивал попытки оплаты, но конверсия в реальный платёж упала на 30%. Что-то блокировало пользователя на финальном шаге.

Никто не поверил результатам. Причем, на всем протяжении эксперимента, в эксперементальной группе всегда было больше участников. Возникла гипотеза, что пользователи перерегистрируются, чтобы попасть в нужный вариант, или что сама система тестирования настроена некорректно. Но подтверждений первому мы найти не смогли.

На графике видны стабильные различия в группах.

AA-тест – Проверка системы

Перед следующей итерацией запустили AA-тест: обе группы видят одинаковый интерфейс. Цель – убедиться в корректности рандомизации и настроек.

Расхождение по ключевым метрикам не превысило 1.5% – в пределах статистического шума. Гипотеза о перерегистрациях не подтвердилась. Система работает корректно.

Эксперимент 2 – Повтор

После подтверждения настроек запустили повторный A/B тест. Он шёл три недели и был остановлен в конце марта 2025.

Смотрите на эти проценты вместе с абсолютными числами. +52.04% по First Payments – это 13 конверсий против 21, а +14.44% по Paid Users – 88 против 107. На форме с ~3 100 визитами в неделю три недели теста дают именно такую выборку. Итоговое резюме самого эксперимента тоже не называет это победой: там сказано, что новая версия показала сопоставимую конверсию.

Так что честное прочтение – паритет, а не рост, и именно паритет был критерием успеха. Решение о выкладке приняли вместе с командой аналитики на этом основании, а не на заголовочном проценте. Можно было бы вынести «+52% первых платежей» в заголовок этой страницы – это были бы те же данные, поданные нечестно, и они не пережили бы первого вопроса про размер выборки.

На этот раз распределение пользователей между группами было нормальным. Причину расхождения в первом эксперименте так и не нашли.

Финальная форма, сценарий с триалами

Результаты

Проект закрыт на 100% от цели, с задержкой из-за провального первого эксперимента.

Дизайн-артефакты: карта всех сценариев оплаты, впервые задокументированная, и биллинговый дизайн-кит с переиспользуемыми компонентами, которые другие команды и дизайнеры могли настраивать под свои сценарии.

Главное здесь – не цифра конверсии. Главное – что 15-летняя форма, через которую шла основная часть платежей, была закрыта силами четырёх команд без потери конверсии, а стоимость каждого будущего изменения платёжной поверхности снизилась вдвое.

Вызовы

Старая форма на legacy-стеке

Значительная часть работы была технической – не дизайнерской. Legacy-стек означал скрытые зависимости и много накрученной логики которую нужно было распутывать. Это требовало постоянной координации между командами.

Провальный первый эксперимент

Падение First Payments на 30% при росте активности пользователей – нетривиальный результат, который не укладывался в интуицию команды. Это потребовало AA-теста для восстановления доверия к данным и дополнительного раунда итераций перед повторным запуском.

Ключевые выводы

• Активность пользователя ≠ готовность платить. Рост попыток оплаты может маскировать проблему на финальном шаге воронки – важно смотреть до конца.
• Провальный тест – это тоже результат. Первый эксперимент дал чёткую гипотезу для следующей итерации и выявил барьер, который без теста остался бы невидимым.
• AA-тест как инструмент доверия. Когда данные вызывают сомнение, проверка системы измерений – это не потеря времени, а необходимый шаг перед следующим решением.
• Процент без абсолютных чисел – не результат. +52% на 13 конверсиях и +5% на шестизначной выборке – это утверждения разного порядка, и вся суть работы – в этом отличии. Определяйте успех по реальному бизнес-кейсу, а затем сообщайте то, что подтверждают данные.