Redesigning checkout for 14M daily visits

AXS ran three separate checkout implementations, built by different teams at different times. None of them agreed. Completing a purchase could take five pages after ticket selection, with constrained mobile layouts, timers that behaved differently page to page, and a login step dropped into the middle of the flow.

Most of those steps existed for a reason. Payment rules, delivery methods, and client requirements were all real. The problem was that the complexity of the system had become complexity for the fan.

Live event ticketing also has a condition most retail checkout does not. When a high-demand event goes on sale, thousands of people enter the flow inside the same minute, competing for finite inventory, mostly on phones. Every seat someone holds is a seat nobody else can buy. A slow checkout does not just cost that purchase. It holds contested inventory while one person works through five pages, and it fails the buyer at the moment they are most worried about losing the seat.

So the cost ran both directions. At 14M+ daily visits, a fraction of a percent is real money for every client on the platform. Three flows meant three things to maintain and three places for client requirements to drift apart. Five pages meant long sessions during exactly the moments when speed and certainty mattered most.

Before designing anything I needed to understand why the existing checkout behaved the way it did, so I mapped it. Thirteen dependency domains resolve inside a single purchase surface, from ticket inventory and pricing through market localization and accessibility policy. Change one variable and several others move with it.

I ran discovery across ticketing strategy, sales, sponsorships, artist services, account management, and global teams. I expected the hard part to be reconciling conflicting priorities. It was the opposite.

Every group wanted the same outcome. The disagreement was never about the goal. It was about the specifics underneath it, and each of those specifics was governed by something outside design.

The central decision was not a layout. It was deciding where consistency created value and where variation was unavoidable.

Structure, hierarchy, module behavior, timer model, and the checkout interaction stay the same everywhere. Payment configuration, delivery options, legal text, translations, and which modules appear can all vary.

That distinction is what kept this from becoming a fourth checkout flow. Anything that varied by client became configuration inside one framework instead of a reason to fork.

My first concept was radically minimal. One screen, nothing extra. Engineering pushed back and they were right. The flow had to handle multiple ticket types, insurance add-ons, accessibility holds, and a long tail of payment edge cases. So I explored two structures instead.

Progressive disclosure came out of the accordion. The core flow stays light and complexity surfaces only when a transaction needs it. A single global timer replaced page-specific timer behavior, so one hold spans the whole purchase and inventory moves faster during high-demand onsales.

The structural change was collapsing five pages into one. The old version buried sign in inside the delivery step, page two of five, which stalled people right after they had committed to a purchase. AXS requires an account to buy tickets and guest checkout was not on the table, so instead of removing the constraint I moved it in front of checkout. Once the purchase starts, nothing interrupts it.

Add-ons had their own page at the front of this flow. Replacing it with modular cards inside the purchase became its own project.

We tested the concept with 15 participants across three age cohorts. It rated 3.9 out of 5 on ease of use and 3.9 on clarity, holding above 3.6 in every cohort.

Mapping the framework against real purchase scenarios made the configuration space obvious. Festivals, multi-event purchases, and Fixed/Flex offers behave differently enough that supporting everything at launch would have meant validating nothing.

We shipped Single Offers first. Establish the framework, validate the interaction, measure it, then expand. Multi-Event, Bundle, Season, and Shopping Cart followed on the roadmap once the foundation held.

The redesign went live as a controlled A/B test in Adobe Target, running 37 days across four purchase contexts. I built the experiment framework, defined the variants, and set success metrics with our PM.

Overall checkout conversion improved 6.5 percentage points. Mobile moved 11.0 points, desktop 2.3. The gap is the story: mobile carried the most traffic and the most friction, and it absorbed most of the gain. The variant beat the control in both Pick a Seat and Best Available contexts.

Conversion was not the only signal. Single Page Checkout reached 97% adoption across events using Single Offers globally. That mattered more than the test result, because the project started with several parallel checkouts creating inconsistency and maintenance load. High adoption meant the framework had actually replaced them.

When I started, AXS didn't have one design system. Different teams were building off different component libraries, so the same elements looked and behaved differently depending on where you were in the product. The patterns I built for this checkout became the foundation for consolidating those into a single global system.

Every module carries the same contract: an active state for input, a summary state that stays editable, and its own validation. Payment forms, add-on cards, and confirmation states were absorbed as foundational components, which meant other teams inherited the decisions without inheriting the flow.

A checkout redesign turned into the starting point for unifying how the platform builds UI.