Orchestrating complexity across a global airline.
British Airways wasn't redesigning a booking flow. It was modernizing a digital platform serving millions of passengers across dozens of markets, built on decades of legacy infrastructure, while balancing operational complexity that most product teams never encounter. I led product design across the Nexus programme, the airline's most significant digital investment in a generation.
British Airways · Nexus — the new booking experience, designed as one system across web and mobile.
At a glance
Investment programme
£7 billion
Project scope
End-to-end
Location
Porto · London
My role
Lead Product Designer
Teams involved
McKinsey, BJSS, BA
Outputs
Web & mobile
The Challenge
Why airline products are fundamentally different.
Legacy carriers don't just have digital products. They have entire ecosystems that must reconcile competing realities: booking systems built across different decades, operational dependencies on ground teams, call centres, and airport infrastructure, and a customer base ranging from first-time leisure travellers to daily transatlantic commuters.
The existing platform had been built incrementally. Features had been added for operational reasons, not customer reasons. The result was a product that served internal needs well and customer needs poorly, measurably so, in NPS, complaints, and call centre volume.
The brief wasn't to improve the interface. It was to rethink the digital experience entirely, while keeping a live service running for millions of passengers, and while aligning stakeholders across McKinsey, BJSS, British Airways digital, marketing, and operations.
Legacy systems
Two decades of accumulated technical and UX debt. Modifying any part risked breaking dependencies across the entire customer journey.
Millions of travellers
The platform needed to serve radically different user types, not as edge cases but as primary design targets simultaneously.
Operational dependencies
Digital decisions intersected with check-in staff, call centres, and ground ops. Design couldn't happen in isolation.
Cross-functional complexity
McKinsey, BJSS, BA product, BA marketing, and BA digital all had legitimate stakes in decisions. Alignment was the hardest design problem.
Understanding the Problem
We started with people, not screens.
The research phase was extensive and deliberate. We spoke directly with BA customers across journey types, reviewed usage data from the existing platform, and worked with BA's own customer insight teams to surface patterns that had been visible in complaints data for years but had never been translated into design direction.
User Interviews & Surveys
Engaging customers across journey types, leisure, business, family, to uncover real frustrations beyond what quantitative data could show.
Usage Data Analysis
Reviewing drop-off points, error rates, and support escalations across the existing platform to identify where the experience was costing the business most.
Historical Research
Leveraging BA's own research archive to understand behavioural trends that had persisted across platform iterations.
Stakeholder Interviews
Customer service teams and ground staff became primary research partners, they held years of front-line insight that had never fed into product decisions.
Key Insights
01
Passengers don't think in airline terminology. They think in journey moments: before, during, after.
02
The most common support escalations weren't feature gaps, they were navigation failures. People couldn't find what already existed.
03
Business travellers had higher tolerance for complexity but lower tolerance for error. They needed reliability, not simplicity.
04
Mobile experience was treated as a secondary channel despite accounting for a significant share of check-in and post-booking activity.
05
Upsell placement was creating friction at the exact moments users were completing high-intent actions. Revenue goals were working against conversion.
06
Ground staff knowledge of common digital failures was entirely absent from any existing feedback loop into product decisions.
Creating Alignment
Design wasn't the hardest problem. Alignment was.
Before a single screen was designed, we ran a series of cross-functional workshops with stakeholders from British Airways digital, marketing, operations, McKinsey strategy, and BJSS engineering. These weren't creative brainstorming sessions. They were alignment exercises with a specific purpose: create shared criteria for what success looks like before execution begins.
Without that shared understanding, design decisions would have been made by whoever was loudest in the room. The workshops gave us a legitimate foundation: documented priorities, agreed constraints, and a shared language across functions that had previously been talking past each other.
“Before changing the experience, we had to change the conversation.”
Discovery and ideation workshops. Customer journeys. Stakeholder sessions.
Teams aligned
BA Digital, Marketing, Operations, McKinsey, BJSS Engineering. Decisions made with, not for, each function.
Method
Journey mapping, current-state critique, priority setting. Structure over brainstorm.
Outcome
A shared product direction that held throughout the project. No significant pivots driven by stakeholder disagreement.
Strategy
Five principles before the first screen.
Before any interface work began, the team established design principles that would govern every subsequent decision. These weren't aspirational values. They were operational constraints: a shared filter for evaluating trade-offs when business, engineering, and design needs conflicted.
01
Design journeys, not pages
Navigation built around airport terminology confused users. We rebuilt it around the passenger experience: before trip, at airport, in-flight, post-journey.
02
Reduce cognitive load
Every decision point was evaluated against the question: does this help the user move forward, or does it stop them? Complexity that served the business at the cost of the customer was cut.
03
Support multiple traveller types
Business travellers, families, first-timers, and frequent flyers had legitimately different needs. The platform had to serve all of them without compromising any.
04
Balance personalization with predictability
Tailored recommendations had to enhance rather than overwhelm. A dynamic platform needed to feel consistent and trustworthy even as it adapted to individual users.
05
Scalable patterns before individual features
A platform at this scale couldn't be designed feature-by-feature. Every interaction had to be designed as a reusable pattern first, a specific screen second.
Nexus future-state service blueprint. Drop 1. Click to open.
Leadership Decisions
The decisions that shaped the project.
Complex products aren't simplified through interfaces. They're simplified through better decisions. These are four that defined the direction of Nexus.
Decision 01
Redesign journeys instead of isolated screens.
Why
The existing platform had been improved incrementally, individual screens had been updated without questioning the journey they sat within. Optimising screens in isolation would have produced a more polished version of the same broken experience.
Trade-off
This required significantly more upfront investment and meant early deliverables took longer. Engineering partners were used to receiving screen-by-screen specifications; journey-based design required new ways of working together.
Outcome
Navigation and information architecture that reflected how passengers actually think, not how the airline's internal systems were structured.
Decision 02
Simplify decision-making instead of reducing functionality.
Why
A common response to complex products is feature reduction. BA's platform needed almost all of its existing functionality, passengers rely on it. The problem wasn't the features. It was how the decision-making burden was distributed between the system and the user.
Trade-off
This made the design challenge significantly harder. It required designing intelligent defaults, contextual surfacing, and progressive disclosure rather than simply removing options.
Outcome
A platform that felt simpler to use without sacrificing the depth that complex itineraries and frequent flyers required.
Decision 03
Build the design system before the product.
Why
At the scale of this platform, designing features before establishing shared components would have created massive inconsistency and technical debt. A modular system was a prerequisite, not a deliverable.
Trade-off
Investment in the design system delayed visible output for several weeks. This required active stakeholder management, particularly with engineering leadership who wanted screens before system.
Outcome
A scalable component library that made subsequent feature design significantly faster and ensured visual and interaction consistency across web and mobile from day one.
Decision 04
Prioritize organizational alignment before implementation.
Why
In projects involving multiple agencies and an internal stakeholder base this large, implementation quality is constrained by organizational quality. Without shared understanding of what we were building and why, even excellent design would have been eroded in delivery.
Trade-off
This required significant time investment in facilitation, documentation, and relationship-building that doesn't appear in design output. It's invisible work that produces visible results.
Outcome
A project that reached implementation with genuine cross-functional alignment, no significant direction changes driven by stakeholder disagreement after the discovery phase.
Designing the Experience
Organized by passenger problem, not by screen.
Interface design began only after the strategy phase was complete. Every step was built on the same components, anchored by a persistent progress tracker so passengers always knew where they were in the journey, from search to confirmation.
Search & compare
Flight results restructured around what passengers actually weigh, price, time, and fare inclusions, instead of airline codes and dense tables.
Choose seats
A seat map that carries the full state of the journey: who is sitting where, what each seat costs, and what an upgrade adds, without leaving the picture of the trip.
Passenger details & review
Trip summary and passenger entry on a single page, with the outbound and inbound flights and fares laid out before a single detail is filled in.
Trade-offs
What we intentionally didn't do.
Strong product thinking includes knowing what to defer. These were decisions made deliberately, with clear reasoning, not because of resource constraints alone.
Advanced loyalty integration
Executive Club integration was scoped but deprioritized. A loyalty-aware platform requires backend APIs that were not yet available. Designing for it prematurely would have created dependencies that blocked core journey delivery.
Full personalization engine
Personalization was designed as a pattern and scaffolded, but full ML-driven recommendations were deferred. Designing the experience for personalization without having live data would have required expensive rework.
Native app redesign
The mobile experience was designed as a responsive web platform. A native app redesign was out of scope and would have split delivery capacity without adding meaningful value at this stage.
Group booking complexity
Complex group bookings (10+ passengers, corporate accounts) were partially scoped but deferred. The user population was small enough that deferral was justified; the complexity would have slowed core journey delivery significantly.
“Complex products aren't simplified through interfaces. They're simplified through better decisions.”
The Solution
One system, from desktop to pocket.
The new platform introduces a flexible, scalable design system that prioritizes personalization, usability, and operational efficiency, holding the same experience together from planning on a laptop to boarding on a phone.
The same components, responsive across the passenger journey on mobile.
Working Across Teams
Design influence isn't given. It's built.
McKinsey strategy team
Strategy consultants and product designers often work at different altitudes. The challenge was creating a working relationship where design informed strategy upstream, not just received strategy and executed downstream. We earned that by showing up with research, not just opinions.
BJSS engineering leadership
Engineering partners wanted component specifications before the design system was complete. Managing that tension required being explicit about why sequence mattered, and then delivering the design system fast enough that the delay was absorbed before it became a blocker.
British Airways digital
Internal BA digital teams had context and institutional knowledge that no external consultant could replicate. The working dynamic that worked best: we brought process rigour and external perspective; they brought operational reality and strategic constraint. Both were necessary.
BA marketing and brand
Brand alignment on a platform this size required more than following guidelines. It required understanding why the guidelines existed, so that when design decisions required interpretation, they could be made with genuine understanding rather than literal compliance.
Impact
Shaping the foundation for the future of digital travel.
The project was still in active development at the point of my engagement ending. Strategic outcomes were visible before final delivery.
Shared product direction
Created a documented, agreed direction that held across six months of development without significant pivots.
Reusable design foundations
Delivered a scalable component library used across web and mobile, reducing design and engineering overhead for every subsequent feature.
Organizational alignment
McKinsey, BJSS, BA Digital, and BA Marketing operating from a shared brief. Reduced time-to-decision by removing ambiguity at the point of delivery.
Scalable interaction patterns
Interaction models built as reusable patterns, not as one-off screen designs, giving the platform a consistent foundation for future releases.
Reflection
What I'm most proud of isn't a screen.
Looking back at Nexus, the work I'm most proud of isn't any particular interface. It's the alignment we created before the first screen was designed. We took a highly fragmented problem (involving multiple agencies, internal stakeholders, legacy systems, and competing priorities) and turned it into something teams could confidently execute together.
That lesson, that the most valuable design work often happens before anyone opens a design tool, shaped everything I did at adidas, Merkle, and now in the AI context. Complexity isn't resolved at the interface level. It's resolved upstream, in the decisions about what to build, for whom, and why.
The work also clarified something about my own role. I'm most useful in situations where the problem isn't fully formed yet. Where the teams are capable but pulling in different directions. Where someone needs to create a shared language fast enough that execution can move.
Next Case Study