A checkout that knows who's paying.
Company travel has rules: who you book for, what your role allows, which cards you may see. I designed the checkout and payment step once, for every product, so those rules show up as fewer choices instead of more forms.
01 · Checkout, before and after
Fewer choices, each one clear.
Pick a note to see it on the screen. The after works: switch who's travelling, or view it as a travel manager.
02 · One checkout, many products
Built once, from blocks.
The legacy checkout was a different page for every product. I mapped every use case, merged the ones that were really the same, and dropped the functions nobody used.
Then I designed the checkout as reusable blocks: trip, summary, travellers, details, extras, insurance, billing, payment and approval. Developers built each block once, and every product assembles its own page from them.
Pick a product to see its checkout assemble.
The same work, said two ways.
One piece of work, every product
The aim was fewer steps and no dead ends at payment, which is where support was losing time. Designed once, it reached cars, flights, stays and trains.
Build a block once
Nine blocks with clear inputs replace a page per product. The rules for roles and privacy live in the data, not in each screen.