A booking platform, rebuilt mid-flight.
01 · The problem
Two years of redesign. Nothing shipped.
When I joined, a new design had been in progress for two years and none of it was live. The legacy product was costing time on both sides of the screen. I started by asking the people who picked up the phone.
- 81%
- said booking was overly complex
- 59%
- said changing a booking was hard
- 37%
- of the support team had lost a booking to complexity
- 48%
- spent 10+ hours a week helping customers book
Source: my interviews and surveys with the customer success and sales teams, 2024.
02 · Search, on four products
Search that remembers what you asked.
The same search had to work for flights, stays, trains and cars, each supplier sending different data. Before is the legacy stays search, after is the flights search I shipped. The full story is its own case study.
03 · Trips
See the whole trip in one place.
Changing anything used to mean starting a new search. The trip view keeps flights, hotel and extras together.
04 · What shipped
Designed and shipped with my squads.
I built the system and the plan, won the funding for an engineering team and two more designers, then designed and delivered these, first sketch to release.
- Design systemBuilt in the new front-end framework with my engineering teamShipped
- SearchFlights, stays, trains and cars, each with its supplier's rulesShipped
- FlightsSearch and results, approvals, pricing and booking rightsShipped
- CarsThe full flow, search to bookingShipped
- Checkout and paymentOne checkout for every productShipped
- Users and rolesAdmin for company travel managersShipped
- Flight extrasClass upgrades, extras, seat mapNearly done
05 · The case studies
Four stories from the same platform.
Each one shows the shipped screen, what I would refine, and the legacy constraint it had to live with.
06 · Two audiences
The same work, said two ways.
A design only ships if the people paying for it and the people building it both understand it. I wrote for each.
Cost, risk and what it unlocks
- “It feels complicated” became numbers: 37% of the support team had lost a booking to it.
- The system pitched with a rollout plan and a clear ask.
- Result: funding for an engineering team and two more designers.
Names, rules and one source of truth
- One developer from the start: I taught him the tokens and we built the first components together.
- Tokens with naming rules, the same in Figma variables and in code.
- Every fare case mapped to one rule string, so a card can’t show the wrong text.
- The ticket card tuned side by side with my developer: hover, shadow, motion.
What changed
From a redesign that stalled to one that shipped.
A funded team, a system in code, and six product areas live on it. The research turned “it feels complicated” into numbers leadership could act on.
What I learned: in a legacy product, half the job is finding out why things are there before you change them.