Booking flow rebuild for a regional travel marketplace

The marketplace converted browsers to bookings at a rate the commercial team knew was bad but could not explain, and the funnel analytics stopped at page level so nobody could see where inside a step people quit. Mobile was the majority of traffic and the worst performer by a wide margin. The brief was framed as a redesign, which usually means somebody wants it to look different; the actual problem turned out to be a passenger details form that asked for eleven fields, four of which were not needed until check-in.

Frontend lead on a squad of four, with a product manager and a designer. I owned the frontend architecture and the instrumentation, and I ran the experiment analysis with the PM.

I built the new flow — the state machine behind it, the form layer, and the resumable draft that survives a browser being closed. I owned the field-level instrumentation, which is what actually located the problem: time-in-field, correction counts and abandonment per input rather than per page. I also did the performance work on the flow, since the old one shipped the entire booking bundle on the first step. The A/B harness and the guardrail metrics were mine.

I pushed to instrument the old flow first and ship nothing for three weeks, against real pressure to just start redesigning. That is what produced the finding — two fields accounted for a third of the drop — and it meant the redesign was aimed rather than general. I chose an explicit state machine over the previous ad-hoc routing because the flow has genuinely gnarly transitions (partial payment, seat held then expired) and the old code expressed those as scattered booleans. I also argued for keeping the flow server-rendered rather than moving to a client-side app: the traffic is mostly mid-range Android on mobile data, and the first-load cost was the thing we were trying to fix.

Peak season was fixed and we could not deploy changes to the funnel during it, which gave us two shipping windows in the year. Payment provider constraints meant one step could not be merged into another no matter how much we wanted to. We also had to keep the old flow running for two partner white-labels that were out of scope, so everything was behind a flag for longer than is comfortable.

Completion on mobile went up by about nineteen percent against the control over a four-week test, and the two fields we deferred to check-in accounted for most of it. Median time to complete a booking dropped from around four minutes to just over two. First-load JavaScript on the entry step went from roughly 480 KB to 160 KB, which mattered more than anything visual we did. The resumable draft recovers about six percent of sessions that would previously have started over.

The product manager ran the experiment design and was the one who insisted we keep a guardrail on refund rate, which caught an early variant that was converting people into the wrong fare. Our designer did the visual work and prototyped the three-step structure. A backend engineer built the draft persistence API to my spec.