Priceline · Lead Designer · Multiple stakeholder
Self-Service Rebook
Cancelling a flight is stressful. Rebooking with credit is worse if you’re not sure what you’ll lose. I designed a guided self-service flow that made the tradeoffs visible enough for travellers to act without calling support.
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 support was one of Priceline’s most expensive service areas. Flight-related contacts made up more than 25% of total call volume — nearly three times the rate of hotel or car — and 729,000 annual calls were tied to flight change-of-plan issues. At $10.75 per call, that translated to roughly $7.8M in operating cost before considering how thin flight margins are. In some cases, one support call could wipe out the profit from the booking.
The opportunity was not just to move a task online. It was to make a high-stakes, policy-heavy flow clear enough that customers could complete it without needing reassurance from an agent.
The Goal
Reduce flight-related support contacts by making cancellation, credit, and rebooking clear enough for travellers to complete on their own. In practice, that meant helping users understand what they had, what they would lose, and what to do next.
User Research Findings
I ran moderated interviews with 8 travellers who had booked flights through an OTA before. I wanted to understand where self-service broke down: what users understood, what they avoided, and when they felt they needed a person.
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
Credits had no home
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.
Support created its own burden
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.
Too much depended on memory
No visual record of cancellation history. Users were forced to rely on emails and memory to understand their own booking status.
The most important finding was not about missing functionality. It was emotional. One participant said she was afraid to cancel because she did not trust herself to understand what she would lose. Versions of that same fear came up across multiple sessions. That changed how I framed the work: the flow did not just need to be usable. It needed to make the consequences visible before users acted.
This wasn't a discoverability problem. This was a fear problem.
MVP Strategy
That research shaped the MVP. If users did not trust themselves to act, adding more functionality would not solve the problem. The flow had to make each step feel understandable and reversible — until the moment it was not.
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 was not a single-team feature. The journey touched four engineering pods, each with its own PM and roadmap, plus Customer Care, Legal, Operations, and Design Systems. It also had CPO-level visibility, so unclear ownership could quickly turn into stalled decisions or scope creep.
Early on, the work was getting buried in coordination overhead: Slack threads multiplied, decisions were reopened, and design feedback came from different parts of the journey without a shared source of truth.
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
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. That operating structure became as important as the screens themselves. Without it, the end-to-end experience would have fractured across teams.
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
My first direction was more structural: a dedicated credit-management surface and larger changes to the trip card. It would have been cleaner for the user, but too expensive for the MVP. Because the journey touched four pods, every new surface created ownership, routing, and maintenance questions.
My Trips · Post Booking · Listings · Checkout
The early concepts explored a dedicated trip-management portal and a credit tab. They solved the visibility problem well, but they also created too much new infrastructure for the first release.
I explored banner treatments that could feel distinct from the standard booking flow without introducing a new pattern from scratch. The challenge was to make the rebook state visible and persistent, while still staying inside the design system and accessibility guidelines.
Because the interaction patterns were intentionally simple, the copy had to do a lot of work. I tested language with users and pressure-tested it with Customer Care to make sure it matched the questions agents were already hearing from travellers.
My Trips · Post Booking · Listings · Checkout
I audited the existing flight listing and asked what still mattered in a rebook context. Some elements from the standard shopping experience became noise, while credit value, fare difference, and policy context became more important. The goal was to adapt the listing card without breaking the underlying booking pattern.
I used the persistent banner as the thread through the experience. It reminded users they were no longer in a standard booking flow, kept their credit visible, and gave policy context at the point where it mattered.
My Trips · Post Booking · Listings · Checkout
The pricing moments needed extra care. If a user picked a cheaper flight, they could forfeit remaining credit. I treated that as a core decision point, not an edge case, because hiding it would almost guarantee support calls later.
Final Design
An end-to-end guided Rebook experience
Content Ownership
Without a dedicated copywriter, I owned the content work end-to-end. I worked with Legal to understand what had to be said, and with Customer Care to understand how travellers actually described the problem. The hard part was finding the overlap: accurate enough for policy, plain enough for a stressed customer.
Airlines write policies for compliance, not comprehension. My job was to translate without losing accuracy. That is why the CTA became “Cancel for Credit” — not “Confirm” or “Proceed.” It described the action and the consequence in the same moment.
Persistent Green Banner
The banner stayed visible throughout the journey and changed as the user moved from cancellation to credit to rebooking. That persistence mattered most on mobile, where context gets lost between screens.
Some stakeholders questioned whether the banner needed to follow users through every step. My answer was always the same: this was an irreversible financial decision made in fragments. The banner gave users one stable reference point while the screens changed around them.
Incremental Pricing
I did not want users comparing retail prices, credit balances, and fare differences in their heads. In the rebook flow, prices reflected the credit already applied, with a “credit applied” badge to signal that the user was still inside the protected rebook experience, not the standard flight shopping.
Forfeit Warning
There was pressure to soften the moment where users learned they would 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 and Tradeoffs
My original concept was a dedicated trip-management portal: one scalable place to manage credits across product lines. From a user perspective, it was the cleanest model. From an engineering perspective, it was too large for the MVP.
I had to decide whether to keep pushing for the ideal architecture or protect the user journey inside the surfaces we already had. I chose the second path. The Cancelled Trips tab became the home base, and the persistent banner carried the credit context that the portal would have owned.
I also worked with the Design Systems team on a new banner variation that could support multiple CTAs and feel informational rather than alert-like. That pattern did not exist yet, but it gave us a feasible way to preserve clarity without creating a new destination.
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 shipped experience moved a high-cost support reason into a self-serve flow that customers could complete with low reported difficulty. It reduced flight-support contacts by 17.5%, saved $1.3M in operational costs, and created a reusable pattern for future post-booking credit flows.
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.