Overview
A booking is a promise. Manage My Booking is where customers come to check we are keeping it.
Nearly every BA journey after purchase passes through the Manage My Booking Hub: changing seats, adding bags, requesting meals, checking flight details. By 2023 the Hub was fighting the people using it. A previous redesign, built on a design language an external agency never finished rolling out, had optimised for air and imagery over findability. Core actions sat inside full-page marketing modules that customers read as adverts rather than servicing. The page stretched into a river of scroll, and revenue-driving third-party services had been folded into a menu that did not read as a menu. Customers said, in writing, that they preferred the older design.
There was a second, less visible constraint. Classic BA.com rendered this page from an XML feed derived from the PNR in a decades-old global distribution system. Like banking, aviation runs on ancient rails. At the same time, BA had launched a £7bn transformation programme that would replatform the entire digital estate. The brief was therefore double-horizoned from the start: fix a revenue-critical surface on a platform with limited life left, in a way that would still matter once that platform was gone.
Focus: Findability, modular navigation, accessibility, personalisation strategy
Scope: UX lead across architecture, the tile-grid system, personalisation rules, accessibility and cross-squad delivery
What I did
Before redesigning anything, I had to find out what was actually there. The Hub had no single source of truth: its pages, journeys and flows had accreted across overlapping legacy versions, and each product team had only partial visibility of the estate behind its own area. Mapping it all myself would have cost months and made me the bottleneck, so I did the opposite. I ran a short IA refresher with the product teams, gave them the basics of site and user flows and the artifacts that hold them, then set each team to map its own product. The output was the Hub’s first shared information architecture. The lasting output was teams who could see and own their own estates.
On that foundation I reshaped the Hub around a modular tile-grid system: every service and offer expressed as a consistent, self-contained tile, card or rail, governed by shared rules rather than scattered across bespoke sections. One legible way for customers to scan everything they could do with their booking, and one pattern for squads to ship into instead of inventing their own. The system held three kinds of content in one grammar: BA’s own ancillaries as a tile grid above the fold, third-party services as a signposted rail pulled back out of the menu they had been buried in, and Holidays as a destination rail placed by genuine propensity rather than wishful prominence.
Accessibility was a design driver throughout, not a remediation pass. The Request Assistance flow earned its own tile, and engagement with its assistance modals rose +37.88%, part of why the structure tested so well across abilities and devices.
The decision: build the container before the data
The ambitious version of personalisation was clear. The grid was built to surface what mattered to a specific passenger: offers shaped by time to travel, by journey stage, by profile and propensity for upgrades or third-party products. The structure could support all of it.
The backend could support almost none of it. A page rendered from PNR-derived XML offers no reliable foundation for profile-driven filtering, and integrating the legacy systems involved was simply not possible. With the replatforming already announced, the contested question became one of investment horizons: how much future do you build into a surface that will be switched off within a year or so?
The call I shaped and argued for was to build the modular container anyway and run coarse rules inside it. We shipped personalisation by destination and time to travel as a deliberate stand-in for the profile-driven version, and accepted that the full design would never run on classic BA.com. What we cut was the data-rich personalisation. What we kept was the structure that made it possible. It is a Bauhaus habit, honestly: define the structural grammar first, then let the modules speak through it. I had built the same instinct designing rails and tiles in streaming, where the catalogue never stops growing and the system has to hold whatever arrives.
That made classic MMB the proving ground. The grid generated the evidence and the rationale for building the same model on the new estate, properly powered this time.
Outcome
I set the redesign up so the call was never mine to win on opinion. The old marketing pods were the control, the tile grid the variation, and live experiments were the arbiter. That is also how you prove a container before it is full: you test the entry-point pattern itself, not the offers behind it.
The pattern won, decisively and at high statistical significance:
- Engagement with seat options up +376%, and baggage engagement up +107%.
- Meals conversion up +34.6%.
- The upgrade entry point up +170%, carrying +18.7% more customers into the upgrade summary and +8.3% through to confirmation.
- A single clearer login CTA lifted progression into the Hub by +1.8%.
I reported the misses too, because that is how you know the wins are real. Baggage engagement more than doubled, yet baggage conversion did not move, so I flagged the flow as the next thing to investigate rather than dress it up as a result. The discipline cut against my own ideas: I once trialled stripping a piece of eligibility messaging to simplify the page, and the data showed it would push more customers into costly support contacts, so I left it in. I treated all of this as leading indicators of revenue, never as clean attribution.
One trade-off I expected and owned: surfacing the core jobs above the fold pushed the flight-details section down the page, and engagement with it fell by around 41%. The experiment caught it immediately. We scored flight-details findability as the highest-priority fix on the backlog and shipped the next round against it: a clear header and summary, the print-itinerary link moved somewhere people could actually find it, the page shortened. Findability recovered, without surrendering the ancillary gains.
The clearest proof it was a system, and not just my page, came when other teams took it. The Help Centre rebuilt its own service navigation on the same tile grid, findability rose, and engagement with contact numbers fell 15.3% on mobile, a leading indicator of people solving their own problems instead of calling.
The structure outlived the platform it shipped on. Manage My Booking in the new BA.com is built on the same modular model, now powered by a modern backend and NDC distribution capabilities that enable the mix-and-matching of BA and partner ancillaries the original design anticipated.
What I took from it
Platform lifespan is a design constraint, and treating it as one is a leadership judgment rather than a compromise. Good enough for a dying platform and foundational for the next one can be the same design, if the structure is right. I learned to argue for that distinction explicitly: ship the value the current rails can carry, and let the work itself become the business case for what comes after.
And the most durable thing I left behind was not the page. It was a pattern other teams adopted as their own, and product teams who could now map and own their estates without me.