role
Senior product designer
focus
Travel & finance
platform
Desktop web
Overview
Unused airline tickets are a cost that travel programs carry without seeing. A ticket is purchased, the trip does not happen, and the remaining value sits unclaimed until it expires.
The request was to let travel managers view, manage, and take action on unused tickets. At the time, those tickets could only be seen inside the online booking tool, which left travel managers without a central view.
Placeholder: prototype video showing sorting by expiration, filtering by status, and the transferability toggle
The existing system
Unused tickets were reachable only through the online booking tool, so travel managers had no single place to see what had been purchased and not flown.
No defined process existed for applying or transferring a ticket, and no one owned the problem. Interviews with travel managers surfaced the same three gaps: visibility, ownership, and financial impact.
[Sizing placeholder: share of unused tickets that were refundable or name-changeable, and the lift in applied tickets where any internal tracking existed. Confirm figures against the deck before publishing.]
Placeholder: stat strip showing the refundable share, the lift where tracking existed, and baseline recovery
The reframe and the model
The research changed the question. The goal was no longer to list unused tickets, but to show which of them could still be used, because that depended on a set of airline-specific rules.
I documented those rules as a decision flow covering when a ticket can be reassigned and when it cannot. That flow became the model the interface had to express in a single table.
The diagram below is the working version of that logic. It is shown at a distance on purpose, since its density is the point: the interface exists so that a travel manager does not have to read it.
Placeholder: back-end transferability decision flow, cropped from the working diagram
Placeholder: toggle states in the table (transferable, non-transferable, not eligible)
The decisions
The central design question was how to handle a toggle inside a table. Each ticket needed to communicate two separate things: whether it could be transferred at all, and whether it was currently set to be transferable.
The team debated several ways to show both signals in a single row. [Add the alternatives considered, why each was set aside, and the cost of the approach that was chosen.]
One control carries both signals. A disabled control marks a ticket that cannot be transferred, and an enabled control shows whether transfer is on or off. [Confirm against the prototype.]
How the model compares
Before settling on the model, I compared how [competitor products to confirm] present unused ticket eligibility and transfer state.
[Add what the comparison showed about separating whether a ticket can be transferred from whether it is currently transferable. Confirm against the research.]
Placeholder: native comparison table of how other products handle unused tickets and transfer state
Outcome
[Add the outcome: whether the model shipped and what changed for travel managers. Include a figure only if it traces to a source.]
[Add what the work showed about designing transfer state for teams with different roles, if the research supports it.]