Solving capacity uncertainty for Priority Pass
Redesign the pre-booking flow to move from a "lounge directory" to a "guaranteed access" service.
TEAM
Product Manager, Developers, Copywriters
ROLE & CONTRIBUTIONS
Research & Synthesis
Drop-off analysis & data review
User scenario mapping
Wireframes
UI & Prototyping
TIMELINE
3 months
TL;DR
Priority Pass members were being turned away from full lounges and the pre-booking feature meant to solve it was buried in an embedded web flow with high abandonment. I analysed drop-off data with the PM, identified four key friction points in the existing flow, and redesigned pre-booking as a native app experience from scratch: fewer steps, earlier capacity signals, reduced flight-entry friction, and a confirmation that carries through to day-of-travel. Conversion rose by X%, driving £1M in revenue across 108k bookings and 304,556 guests served globally.
180k
Bookings
304,556
Guests served
SOLUTION
Here are some of the key flows
Pre-book surfaces where member intent already exists.
Members approach this feature from different moments: searching for an airport, revisiting a saved lounge, or reviewing an upcoming trip. Rather than a separate discovery flow, the entry point was embedded across all three surfaces so it appears at the moment the intent to visit a lounge already exists, not a step before it.
Each design decision in the native flow was mapped to a known drop-off.
Simplified flight search, guest limits were explained in context rather than surfaced as errors, and the cost breakdown moved before payment confirmation.
Extending the experience past confirmation.
The web flow ended at a confirmation screen with nowhere to go. Connecting the booking to the Card tab turned confirmation into a functional reference on the day of travel: lounge name, check-in time, guest count, and booking ID ready at the door alongside the membership card.
OVERVIEW
Powering seamless travel experiences
Priority Pass partners with leading financial institutions and travel brands to provide airport lounge access and travel experiences to millions of members worldwide. As its partner network and membership offerings grew, the product needed to evolve to support increasingly complex membership journeys.
40 million members
Lounges in over 40 airports
PROBLEM
Members said they wanted pre-booking. The data showed something else.
52% of frequent travellers said they would pay a reservation fee to guarantee lounge access. The demand signal was clear. But the percentage of members who actually completed a pre-booking was very less, a gap that pointed to something beyond awareness or intent.
THE SITUATION
130%
over pre-pandemic capacity at some locations
THE DEMAND SIGNAL
57%
Of frequent travellers said they'd pay a fee to guarantee lounge access
THE PROBLEM
Web experience
A pre-booking flow buried in a third-party web experience
The experience was asking members to leave Priority Pass to make a Priority Pass booking. Pre-booking ran as an embedded web flow inside the app visible enough to reach, but disconnected enough to feel like a handoff to a third party.
INSIGHTS
The feature existed. Members weren't completing it.
My first instinct was to understand where members were leaving, not just that they were leaving. Working with the PM, I pulled analytics drop-off data and walked the embedded web flow step by step looking for patterns rather than treating abandonment as a general problem.
Flight-number search which was cognitively heavy and time-consuming
A pre-booking flow buried in a third-party web experience
The flow didn’t align with users’ existing mental models of booking.
But was this just a technical problem?
No. The deeper issue was structural. The flow was ordered around what the API required not how a member thinks about booking a trip. Every step after flight entry assumed a readiness that the entry point itself had already broken.
Hypothesis
"If we align the flow with how users actually book travel, rather than how the API requires data, we will bridge the gap between user anxiety and a guaranteed lounge experience"
DESIGN PROCESS
Starting from the web flow and working through it using step by step
I used the existing web flow as a baseline and walked through every step the way a member would encounter it. Each moment that required effort the member shouldn't have to spend became a candidate for change. The working principle was friction forward: find where the flow asked too much, and redesign that step first.
Key insight
Another key feature, the Busyness Indicator, was ready for implementation. We explored how it could be used to inform users about expected lounge busyness and encourage pre-booking during peak periods.
Reducing friction at the moments that mattered most.
I compared each step against the Tableau drop-off data and noted what the experience was asking versus what a member was likely to know or have ready at that point in their journey. Those gaps became the brief. Below are some of the key changes that came out of that process.
Before
Members were asked for flight number most people do not have their flight number memorised, making it a barrier before the booking had even started.
After
The flow now asks for date and entry time, with a "Find my flight time" option as a backup for those who need i
Before
Arrival time was a dropdown, hiding all options until tapped.
After
Available slots are displayed as a button grid visible at a glance, easy to tap.
Finally, the first version was ready for cross-team review.
I mapped every booking state that changes what someone sees: current, past due, hardship, paid ahead, paid off, and the edges in between. Each state got three screens. Home is the snapshot. Loan details is the summary. Extended view is the full breakdown. When the set was complete, I took it to PM, engineering, and design
Product opportunity
As pre-booking was being designed, the Busyness Indicator reached implementation readiness. Rather than launching it as a standalone feature, we integrated it into the same journey giving members the context they needed to make informed booking decisions
Getting stakeholder buy in
Reviews and rounds of iterations are hard, but they are key to turn stakeholders into advocates for our work. I knew it was crucial to listen and address concerns, without forgetting we had to be assertive about some of the design direction we chose, and showing the value in our design direction.
One way I get buy-in is by showing the direct value and speak to the stakeholders directly. I showed the Head of Product simple before / after of how simple the app architecture got after the changes and she immediately reacted positively.
DESIGNING WITH CONSTRAINTS
API limitations forced me to rethink the design again
The original plan placed lounge bookings inside Trips the natural destination for anything travel-related. When the Trips API didn't ship in time, directing members there was no longer an option.
Rather than leaving confirmation as a dead end, we pivoted to the Card tab adding a Bookings view alongside Memberships. Members already go to Card to show their pass at the lounge door. Putting the booking there meant both pieces of information were in the same place at the moment they were needed most.
Before
Creating a trip from the booking details
After
Showing all the access details and booking details in one place
INTEGRATING BUSINESS INDICATIOR
Context over interruption
The busyness indicator was embedded within the lounge details where members naturally evaluate their options. This provided timely context to encourage pre-booking during peak periods without disrupting the browsing experience.
OUTCOMES
Impact 1 month post launch!
108k
Bookings generated
300K+
Guests served through the pre-booking flow since launch
REFLECTION
My key takeaways and learnings!
Map edge cases before screens
The pre-book flow had many states: flight not found, lounge at capacity, booking window passed, guests exceeding limits. I handled most of these reactively. AI could help map every state upfront so edge cases are designed in rather than caught late in review.
Validate mental model assumptions earlier
The insight that members know their flight time but not their flight number came from data analysis, not early testing. AI-assisted research could surface that kind of assumption much sooner before a flow is already built around the wrong input.
Update as of June 2026
Remember the API that wasn't ready? It is now.
The full trips feature is launching soon giving members an end-to-end experience to find, book and save their visits in one place.
Check back in a couple of weeks for the case study.
