Ryanair. Booking flow design for millions of customers.

This work is restricted under NDA. Specific details and metrics are not shown here.

The impact

Embedded product designer on the squad responsible for Ryanair's main booking flow during the 3.0 redesign — working to reduce drop-off, improve policy comprehension, and increase conversion on higher fares, with every decision measured against live traffic from millions of users.

The context

Ryanair's booking flow is one of the highest-volume purchase funnels in European travel. At the time of the 3.0 redesign, the product was carrying hundreds of millions of passengers a year. A 1% improvement in any conversion step wasn't a minor win — it was material at that scale.

The 3.0 redesign was a wholesale rebuild of the booking experience: new design system, new information architecture, new interaction patterns across the full purchase flow. My squad owned the core booking steps — search, fare selection, bags, seat selection, and payment summary.

My role

UI Product designer, embedded in a cross-functional squad. I owned design across my squad's surfaces end-to-end: discovery, design exploration, prototyping, stakeholder reviews, and developer handoff. Decisions were validated against a data framework combining quantitative analytics (session data, funnel drop-off, heatmaps) and qualitative research (usability testing, user interviews).

Working at Ryanair meant operating under a strict data-driven culture: design proposals without supporting evidence didn't move forward. Every direction was grounded in funnel analytics before it reached prototype stage.

The three problems

Flight Summary Page: bounce before purchase

The Flight Summary Page — where users review their selected flights before proceeding to checkout — had an elevated bounce rate that wasn't explained by price. Users were reaching the page, reviewing, and leaving without completing. Session analysis and usability testing revealed the issue: the page was surfacing information in an order that created doubt rather than confidence. Users were encountering restrictions, fees, and policy notices in places that read as obstacles rather than confirmations. The information was accurate; the hierarchy was undermining trust at the moment it mattered most.

The design work focused on restructuring the page around confirmation, not disclosure. What users needed to feel at that moment was: this is the right flight, this is what I'm paying, here's what happens next. Policy information didn't disappear — it was repositioned where it belonged contextually rather than where it was technically convenient.

Bags policy: comprehension failure at a critical step

Ryanair's bags policy is objectively complex: multiple bag types, size restrictions, weight limits, and rules that change depending on fare tier and route. The existing design surfaced this complexity without translating it. Users regularly misunderstood what they were buying, leading to a combination of abandoned purchases and post-booking support tickets from customers who arrived at the airport with the wrong bag allowance.

The design challenge was comprehension, not just layout. Usability testing showed users weren't failing to read the information — they were reading it and still getting it wrong. The policy copy was technically accurate and functionally incomprehensible. The solution required working on the information architecture of the selection step alongside the UX writing. Options needed to be framed in terms of what users were actually deciding ("Can I bring my carry-on bag?") rather than in terms of product taxonomy ("Priority boarding + 2 cabin bags").

Higher fare conversion: misunderstood value

Ryanair's higher fare tiers include flexibility and perks that have real monetary value for frequent travellers — but conversion on those tiers was underperforming what the pricing suggested it should be. The product was treating fare comparison as a feature matrix problem. Usability testing revealed it was actually a trust problem: users didn't believe the higher fare was worth it because they didn't understand what they were actually getting, or didn't trust that the described perks would work as advertised.

The design work focused on making the value concrete and specific rather than abstract and comparative. Showing what a flexible ticket actually means at the moment of flight disruption, rather than listing "flexibility" as a row in a comparison table, changed how users evaluated the upgrade.

What the scale teaches you

Designing for a funnel at this volume changes how you think about decisions. Changes that feel small in a prototype — a label rewrite, a reordering of steps, a default state — produce measurable effects within days of deployment. That feedback loop is clarifying: it removes the ambiguity about whether a design choice mattered. It also raises the bar for how rigorously you need to justify a direction before shipping it.

The data-driven framework wasn't a constraint on creative work. It was the thing that made the work legible — to the team, to stakeholders, and to me.