Priceline · Lead Designer · Multiple stakeholder
Self Service Rebook
Empowering travellers to cancel and rebook flights digitally, eliminating a multi-million-dollar support cost while building the kind of trust that keeps them coming back.
17.5%
Reduction in flight-support contacts
$1.3M
In operational savings
$10.75
Cost/support call eliminated
729K
Annual calls that drove business case
The Business Problem
Flight-related customer service calls made up over 25% of total call volume at Priceline — nearly three times the rate of hotel or car. In 2023, 729,000 calls related to flight change-of-plans were logged. At $10.75 per call, that's $7.8M in operational cost for that reason code alone — before accounting for the fact that flights run on 3–5% margins, meaning a single support call could cost more than the entire booking profit. This was the reason code we set out to solve.
The Goal
Reduce flight-related support contacts by giving travellers the confidence to cancel and rebook on their own, without a call, and without fear of making a costly mistake.
User Research Findings
I ran a moderated interview study with 8 users who had previous OTA flight experience.
Fear of complex interfaces
Too much text to scan, or fear of making irreversible mistakes that would cost money. Users needed enough clarity to trust themselves in a self-serve flow
No credit visibility
Travel credits existed only as emails. No record of them on Priceline meant users didn't know what they had — or how to use it.
Long wait times
Multiple calls to resolve a single issue. Long hold times. Cognitive overload from trying to track complex airline policies over a phone call with no visual aid.
Mental recall burden
No visual record of cancellation history. Users were forced to rely on emails and memory to understand their own booking status.
The most resonant finding wasn't about features — it was about fear. The first user said she was afraid to cancel because she didn't trust herself to understand what she'd lose. The same sentiment echoed through multiple sessions. This was a lightbulb moment and helped me frame the whole project
This wasn't a discoverability problem. This was a fear problem.
MVP Strategy
The fear finding shaped everything. If users didn't trust themselves to act, a more powerful feature set wouldn't help. We needed a flow that made every step feel safe and reversible until it wasn't.
With the research and insights in mind, my PM and I spent time aligning on what success looked like, and we aligned on four principles for the MVP:
1. Step by Step
guided, intuitive flow that leaves little room for error, and therefore builds trust
2. Increased Transparency
on fees and policies without overwhelming users
3. Reduce Dependency
explicitly reducing support dependency as a primary success metric.
4. Minimise Tech Debt
by scoping tightly to existing design system components
My core job to be done: design a trustworthy end-to-end flow within significant technical and content constraints.
Cross-Functional Complexity
This wasn't one team. It was four separate engineering pods, each with their own PM and priorities, plus customer care product, legal, and operations. The project had CPO-level visibility, which meant alignment had to be right.
Early on we were drowning in overhead. Slack threads multiplying, decisions being made and unmade.
Post Booking
My Trips
Confirmation Page
Wallet (did not exist at the start of the project)
Listings & Details
Flight Search Results
Flight Details
Site X
Flight Search Landing Page
Checkout
Trip Summary
Checkout
*consolidated into one page as part of refresh
Early on we were drowning in overhead. Slack threads multiplying, decisions being made and unmade. I identified the structural problem: no shared decision log, so nothing ever stuck. I proposed a weekly sync across all four pods with a shared decision log in Confluence. It cut redundant threads significantly and gave stakeholders a single place to track open questions. This also meant design wasn't blocked waiting for async alignment and I could ship explorations with documented assumptions and get structured feedback in one session. This structural fix was as important as any design decision I made on this project and prevented scope creep that kills scaled projects like this
Design Process
The question I was trying to answer with these variations was: what's the minimum information a user needs to feel confident enough to act within that touchpoint?
My Trips · Post Booking · Listings · Checkout
Initial explorations required too large an engineering lift — creating a new Trip Credits tab and making heavy changes to the Trip card would have created significant tech debt across four pods.
My Trips · Post Booking · Listings · Checkout
Initial design concepts consisted a trip management portal, as well a credits tab on the bottom of the page, but these would be too large tech lifts
To give the cancel for credit and rebook feature its own cohesive visual feel, I explored many different banner color and typeography variations that meet usability guidelines but did not require a large tech lift from teams involved
I built on existing design system patterns, focusing heavily on copy. I ran user testing and worked closely with the customer care team to find language that actually resonated with customers going through a stressful moment.
My Trips · Post Booking · Listings · Checkout
I audited the existing flights listing to identify what needed to change for a rebook context, suppressing irrelevant elements and modifying the listing card without disrupting the standard booking experience.
To create a guided experience, I brought in the green banner to the top of the page to ensure a cohesive look and feel, as well as ground the user + keep them informed on any important policies
My Trips · Post Booking · Listings · Checkout
An important part of this end-to-end journey was ensuring that the user understood how they were being charged. The forfeit scenario was especially important, and I wanted to ensure that the users were aware if they were going to lost any money
Final Design
An end-to-end guided Rebook experience
Content Ownership
Without a dedicated copywriter, I owned the content work end-to-end — working with legal on what was required and with customer care on how users actually talked, then finding the intersection. Airlines write policies for compliance, not comprehension. My job was to translate without losing accuracy. The CTA is 'Cancel for Credit' — not 'Confirm' or 'Proceed.' That was deliberate: it tells the user exactly what they're agreeing to and what to expect next.
Persistent Green Banner
The banner appears at every stage of the journey, always updated, always showing the user exactly where their credit stands. On mobile, users lose context between screens. This was the one constant that kept them oriented through a multi-step, high-stakes flow. Engineering and stakeholders kept asking why it needed to persist — my answer was always the same: because this is an irreversible financial decision made in fragments.
Incremental Pricing
I didn't want to show users the retail flight price and ask them to do the math. Prices already reflect the credit applied, with a 'credit applied' badge that signals the user is in a protected, guided experience — not the standard booking flow.
Forfeit Warning
There was real pressure to de-emphasise the moment where a user sees they'll lose remaining credit on a cheaper flight. My position was the opposite. A user who discovers they lost $30 after the fact is a support call, a churn risk, and a negative review. A user who sees it upfront might hesitate — but they're an informed customer who booked anyway. I made that case using the research. Users who noticed the clear forfeit messaging told us it actually built trust.
Working Within Constraints
My original concept was a dedicated trip management portal — a scalable surface for managing credits across all product lines. Engineering came back and said it was too large a lift. I had to decide: fight for the portal, or find a more feasible path.
I pivoted, but was deliberate about protecting the user journey. The portal would have given users a single place to manage all credits. I replicated that function using the existing Cancelled Trips tab plus the persistent banner. I worked closely with the design system team to develop a new banner variation that could carry multiple CTAs and feel informational rather than alert-like, which didn't exist in the system.
Outcome
17.5%
Reduction in flight-support contacts
$1.3M
In operational savings
1-3/10
task difficulty rating from users, where 1 = easiest.
5%
Projected increase in operational savings for following year
The redesigned experience helped Priceline move flight support from one of its most costly touchpoints into a self-serve flow users were actually confident using.
What I'd Push on Next
Self-serve for flights was always meant to be the first domino. The architecture I built — the persistent credit banner, the guided flow pattern, the cancellation policy translation work — was designed to be replicable across hotel and car. I'd want to push that expansion forward, and do it with the full design system alignment in place from the start rather than retrofitting it.
The content side is also unfinished. I owned the policy translation end-to-end on this project without a dedicated copywriter, which worked, but it's not scalable. Building a proper content framework for how Priceline communicates fees, credits, and policy constraints across the post-booking experience would have compounding impact far beyond this one flow.
And with AI tooling now available that wasn't when this project shipped, I'd revisit the forfeit warning logic. Right now it's a static threshold — credit remaining over a fixed amount triggers the warning. A smarter version would surface it contextually, calibrated to the user's booking history and risk tolerance. Same protection, lower friction for users who've been through it before.