One traveller
A guided path for one booking and one possible refund, with alternatives when access to data felt too sensitive.
Work / QYVO
Travel techProduct strategyDesign leadershipUX researchUX/UI
QYVO
A product that gets back the travel money that goes missing after booking. It started as a consumer service and grew into a working platform for travel-management teams.
01
One problem, two very different operating contexts
The refund was real for a single traveller. For a team that had to find, prepare and account for refunds over and over, it mattered much more.
After a trip is booked, unused tickets, taxes, fees, travel credits and some extras can leave money on the table. The proof is scattered across airline policies, booking records, inboxes, expense systems and spreadsheets.
The first version helped one person spot a claim and pursue it. Research showed that not everyone will hand over access to their bookings and inbox, so the B2C flow also took file uploads and forwarded emails. For teams handling many travellers and bookings the same problem was much bigger.
The B2B/TMC product makes the work visible: connect your data, find opportunities, prepare a claim, follow its status and report the result.
02
Recovery only works when the whole loop stays visible
Intake, decisions and results run in one shared rhythm.
Connect
Start with the data a team already has: GDS, expense platform, email or an uploaded file. More than one way in keeps trust high and adoption realistic.
Detect
Show a potential recovery opportunity with its source and reason, so a person can judge the case before acting on it.
Operate
Keep every claim in an explicit state: detected, draft, submitted, needs info, recovered or denied. A team cannot manage a queue with implied status.
Report
Return to the operational picture: recovery, status distribution and performance over time, without rebuilding the story by hand.
03
The pivot changed the product shape
A consumer assistant became a team workspace. The problem stayed the same. The design now had to handle who owns what, integrations and reporting.
Many bookings
A claims queue with explicit state, source and context for people who operate recovery across an organisation.
One operating view
Connections and reporting turn single claims into a practice the team can see and repeat.
04
Four screens made the operational model usable
Each screen carries a decision about what a travel team needs to see and do next.
Orientthe day starts with a recovery queue
A dashboard that turns scattered value into a prioritised view
The dashboard puts active recoveries and opportunities you can act on in one place. A team has a place to start without digging context out of separate systems.
Product data in the interface is illustrative; the proof here is the designed operating model.
Operatethe case is a managed object, not an inbox thread
A claim workspace with states a team can actually act on
Claims hold a consistent status, traveller, booking and value context. The queue makes ongoing work inspectable across more than one person and more than one trip.
Clear states stop a refund from turning into a to-do nobody can trace. A denial or missing information is as visible as a recovered refund.
Integratetrust needs more than one door in
Data connections that accommodate how travel records actually arrive
GDS, expense, email and file upload sit alongside each other. This keeps a lower-commitment route available while enabling connected intake for a travel operation.
It doesn’t promise one integration for everything. It makes the ways in easy to read and gives the team a clear next step.
Explainthe recovery work must be accountable
Reporting that brings individual claims back to the operating picture
Reports bring recovery totals, status distribution and trends into one view a team can come back to. Progress becomes a shared conversation, not an export.
Values shown inside the interface are illustrative. Recovery reporting was designed as a core product area, alongside the operational workflow.
05
The work moved from research to two shipped product scopes
The direction changed along the way, and the work followed it.
Research
Mapped the recovery problem across six airline processes
The UX Researcher led the studies, process analysis and benchmarking. I framed the questions, joined the research and synthesis, and turned it into product direction.
38+ documented hours
B2C
Designed ways to submit booking data without making trust an all-or-nothing decision
Manual file upload and forwarded email offered alternatives to connected access in the consumer flow.
trust alternatives
Pivot
Reframed the same recovery problem around team operations
The product moved from one traveller and one booking to batch workflows, shared ownership, integrations and reporting.
B2C → B2B/TMC
Delivery
Shipped the consumer and travel-management scopes
I led design direction, workflow, reviews, schedule, deadlines and budget while contributing hands-on across research, UX and UI.
12-month projecttwo delivered scopes
“The pivot did not abandon the recovery problem. It gave teams the visibility and repeatability needed to solve it.”
QYVO product direction
06
I led the design system and the people using it
I gave direction, coordinated and worked hands-on. The specialists’ work stayed visible as theirs.
Design direction
Set product and UI direction across the B2C and B2B/TMC scopes.
Research
Framed questions, joined the work and synthesis; the UX Researcher led studies, analysis and benchmarking.
UX and UI
Defined architecture and contributed hands-on while the UX and UI Designers developed parts of their specialist workstreams.
Design operations
Owned workflow, reviews, schedule, deadlines and design budget through delivery and design QA.
07
The outcome was a product that could change markets without losing its logic
What was delivered, and what was measured.
QYVO is about product judgment under uncertainty. Research exposed a trust barrier, and the answer was a different operating model, not a cosmetic fix to the first journey.
Both scopes were delivered during the 12-month project. 3,000 verified sign-ups in the first 10 days showed there was demand.