Reimagining
the Payment Experience
Designing a scalable payment experience for the Connected Trip while stabilising a business-critical platform migration
Summery
Organisational Impact
-
Influenced the 2021 Payments roadmap.
-
Established a shared long-term UX direction for Payments.
-
Aligned multiple verticals around a product-agnostic payment model.
-
Created stronger collaboration between Design, Product and Engineering.
-
Introduced UX reviews into the production QA process.
-
Created an experimentation model for progressively delivering the vision.
-
Raised Design's role from UI execution to product strategy and measurable business outcomes.
Role in the work:
-
I led the programme from strategy through experimentation and delivery. I pitched the redesign and was responsible for establishing both the design direction and the process used to get there.
-
-
My responsibilities included:
-
Defining the UX strategy and project roadmap.
-
Planning deliverables and decision checkpoints.
-
Facilitating HMW, ideation and critique workshops.
-
Leading UX audits and synthesising existing research.
-
Directing the future Payment Component experience.
-
Coordinating designers, researchers and copywriters.
-
Working with Engineering on technical feasibility.
-
Aligning Payments, Wallet, verticals, Design Systems and Design Leadership.
-
Directing prototypes and usability testing. Breaking the vision into testable experiments.
-
Using experiment results to determine what shipped.
-
Introducing UX reviews into the team's production process.
Impact
+2% conversion
The new tappable payment-selection UI increased mobile-web conversion by 2% compared with the previous Payment Component UI, bringing migration performance within the acceptable threshold.
+0.42% estimated desktop improvement
A second desktop iteration generated an estimated +0.42% conversion improvement, enough to move the experiment to full rollout.
Migration stabilised
The design interventions helped bring web performance within the acceptable migration threshold, supporting a business-critical transition to Booking.com's new payments infrastructure.
Vision → Roadmap
Features originating in the Payment Component vision entered the 2021 Payments roadmap and were prioritised for further experimentation.
Design → Operating model
The work exposed a gap in the development process: Design wasn't systematically reviewing implementation before release.
I introduced UX reviews before production, making design quality part of the team's QA process rather than something evaluated after launch.
The context
Booking.com was undertaking a business-critical migration to a new payments platform, an important foundation for the company's future payments strategy.But we were changing two things simultaneously: the underlying payment technology and the customer experience.
The existing Payment Component had not been designed to support the growing complexity of Booking.com's payments ecosystem. It needed to work across multiple travel verticals while supporting emerging capabilities including credits, vouchers, instalments and different payment timings.
I pitched and led a redesign of the Payment Component alongside the migration.The ambition was bigger than refreshing the UI. We wanted to establish a product-agnostic payment experience capable of scaling across the Connected Trip, while addressing existing customer friction and giving individual verticals enough flexibility for their specific needs.
When the web migration began struggling on conversion, however, we changed strategy.Rather than pushing the complete vision into production, I worked with Product and Engineering to break it into smaller experiments, identify our highest-confidence customer improvement and progressively ship the experience.
The result was a 2% conversion increase on mobile web, stabilisation of the web migration, rollout of the new payment-selection interaction, and several vision concepts entering the 2021 Payments roadmap.
The challenge
The payment experience wasn't designed for where Booking.com was going.
At the beginning of 2020, the Payment Component team needed to define how the experience should evolve to support Booking.com's Connected Trip strategy.The existing component had accumulated significant usability and scalability problems.
Customers struggled to understand:
-
How do I pay?
-
What can I pay with?
Payment methods were hidden behind additional levels of interaction, and on apps, adding or selecting a credit card could require navigating several layers.At the same time, the internal product had become increasingly difficult to scale.Different verticals required different layouts and styling.
New payment capabilities were emerging.And the component needed to support future products including:
-
Credits
-
Vouchers
-
Instalments
-
Different payment timings
-
Alternative payment methods
We needed to solve today's usability problems without designing ourselves into another corner tomorrow.
Establishing the baseline
Before redesigning payments, we needed to understand the entire system.
We started by mapping the existing Payment Component across Booking.com's verticals and platforms.
We:
-
Mapped the existing end-to-end flows
-
Audited the UI across verticals
-
Reviewed existing customer and product data
-
Analysed the payments landscape
-
Created a customer-problem checklist
-
Synthesised the evidence into strategic themes
This allowed us to separate isolated UI problems from systemic experience problems.
One issue appeared repeatedly:Selecting a payment method was unnecessarily difficult, customers saw payment icons but didn't always understand how to interact with them. Additional methods were hidden behind dropdowns and the interaction became increasingly complex on smaller screens.
This wasn't just visual friction.It was friction directly in the path to conversion.
Defining the strategy
The research and audits helped us converge around four strategic themes.
-
Universal Checkout
Move toward a consistent way for Booking.com's travel products to handle payments across the Connected Trip—and eventually within a single basket.
-
1-Click Experience
Reduce unnecessary interaction and move closer to a fast, seamless checkout.
-
Product-Agnostic Customisation
Create a shared component while defining how much flexibility individual travel verticals genuinely needed.
-
HOW + WHEN of Payments
Bring together how customers want to pay and when they want to pay, surfacing the most relevant options for their context.
These themes gave the team something more durable than a collection of UI improvements. They defined what the Payment Component needed to become.
The central design tension
Consistency → Flexibility
The Payment Component needed to create a consistent Booking.com payment experience but every travel vertical had legitimate differences.
Some wanted different headers, some needed different instructional content. Some required different visual treatments and different payment methods introduced their own requirements.
Giving every vertical complete flexibility would recreate fragmentation. Removing all flexibility would make the component impossible for teams to adopt.
Decision
We moved toward a product-agnostic core with controlled customisation. The underlying interaction model remained consistent while specific elements could adapt to the product context.
The principle became:
Standardise what customers need to recognise. Flex what the product genuinely needs to change.
Designing collaboratively
I deliberately separated idea generation from decision-making.
I created a shared Figma environment where designers across the Payments track could independently explore solutions while seeing and building on each other's ideas. We then brought senior and lead designers together to critique those concepts.
Ideas were shared.
Assumptions were challenged.Concepts were voted on.
The strongest directions were brought together into a coherent experience, which I then took into broader cross-functional critique.That gave us a deliberate progression: Diverge → Critique → Prioritise → Combine → Prototype
Experiment → Learn → Iterate
Mobile Web
-
We introduced the tappable payment-method UI.
-
Result: +2% conversion versus the previous Payment Component UI.
-
The improvement brought mobile web back within the acceptable migration threshold.
-
The experiment went FULL ON.
Android
-
The first Android experiment ran for two weeks but was inconclusive.
-
We identified contradictory prices and charge amounts as a possible confounding factor.
-
Instead of treating the result as validation or failure, we fixed the experience and restarted the experiment.
-
We also began experimenting with branded CTAs for payment methods such as Google Pay and PayPal.
-
This became the operating model:Ship → Measure → Understand → Iterate.
Desktop
-
We applied the same principle.
-
The first version improved performance but wasn't sufficient.
-
Rather than abandoning the direction, we iterated.
-
We increased the size and prominence of the tappable payment options, bringing the experience closer to the existing baseline while preserving the new interaction.
-
V2 improved conversion by an estimated +0.42%, enough to go FULL ON.
Key Trade-offs
Future vision → Migration stability
The complete vision represented where we wanted payments to go, but pushing too much change during a critical platform migration increased business risk. We separated the North Star from immediate delivery and shipped the highest-confidence improvements incrementally.
Dropdown → Direct selection
Dropdowns reduced visual complexity but hid important payment choices and introduced additional interaction. Customer behaviour consistently showed an expectation that payment icons were directly selectable, so we made them tappable.
Consistency → Controlled customisation
A completely rigid component couldn't accommodate legitimate differences between travel products, while unrestricted customisation would recreate fragmentation. We established a common interaction model with carefully controlled flexibility.
Big redesign → Small experiments
Rather than treating the vision as one large release, we decomposed it into independently testable changes. That allowed us to learn faster and reduce migration risk.
Usability evidence → Business evidence
Positive usability testing wasn't enough. We used controlled experiments to determine whether design improvements actually protected or improved conversion before scaling them.
Lessons
A vision doesn't need to ship all at once to create value.
The original ambition was significantly larger than the interaction we eventually shipped first. That wasn't a compromise of the strategy, It was how we made the strategy executable.
The North Star told us where we wanted to go, research told us which problems mattered, engineering constraints told us what was feasible and experiments told us whether we were actually improving the business.
The most important design decision wasn't creating the largest possible redesign.It was identifying the smallest change we had the strongest evidence would make the experience better, shipping it, measuring it and using that learning to move toward the larger vision.
From redesigning a component to changing how Payments built products
We started with a Payment Component that wasn't scaling with Booking.com's product or technology ambitions.We established a future vision, tested it with customers, and then adapted our approach when the business-critical migration came under pressure.
Instead of choosing between long-term vision and short-term performance, we used one to guide the other. The result was a payment experience that was easier to use, a migration that could progress, measurable conversion improvement, a clearer Payments roadmap and a more evidence-led way of delivering UX across the organisation.