Product Strategy
Systems Thinking
Research
Operational UX
An early concept for the booking view. Itinerary on the left, one timeline of notes and system events on the right. Rounds of mock-ups like this kept uncovering problems in how TSA stores booking data.
Role
Lead designer
Scope
Discovery for TSA, the internal booking platform used by customer service agents
Team
One other UX designer, product manager, BAs and finance
Timeline
12 weeks
Outcome
Redirected TSA from a UI refresh to fixing the data; now being built by engineering
Status
Paused, then picked up by engineering
In short
TSA is the internal platform customer service agents use to manage bookings, and it hadn’t had any design work in 20 years. The project was briefed as a UI refresh to fix usability issues agents had been raising.
I interviewed agents and reviewed hundreds of call recordings, and found that the biggest problems came from how TSA stores booking data, not from the interface. After several rounds of mock-ups kept uncovering new problems, I took the case to the Chief Digital Officer: this couldn’t be solved as a UI refresh, and it needed more discovery into the underlying data structure so the architectural problem could be fixed first. The project was paused. In Q4 2026, it was picked up again as an engineering-led, AI-assisted build, using my research and early concepts as a starting point.
001
“
You just can’t rely on the information you see on the top level, because you have to double-check the notes.
— Customer service agent, Manila
“
Agents have incorrectly quoted refund amounts because of this error in TSA, which is causing financial impact… we have to honour the refund that was quoted.
— Finance team member, Manila
“
It’s much more complex, yet we’re expecting the same agents to handle that complexity.
— Customer accounting team member, Melbourne
TSA, before and after. Drag to compare the booking screen agents use today with the redesign concept.
The brief
The brief was a UI refresh. Agents had been complaining about usability issues, and the expectation was that these could be fixed in the interface.
I had never used TSA, and only customer service agents use it, so I started by talking to the people who use it every day. I led the discovery and the design direction, with another UX designer supporting.
002
Talking to agents
I interviewed 10 agents in Manila, who handle customer calls directly, and people from the service portal team in Melbourne, who are accountable for how the platform performs. The same problems came up in almost every conversation:
Booking details are hard to read at a glance. Booker and passenger details, products, ancillaries and payments are all there, but not organised. Agents piece together the context at the start of every call, which slows verification and lengthens handling time.
There’s no reliable booking history. TSA has no clear timeline of what changed and when. Agents rely on a free-text notes box, written by hand after every call, to understand a booking. This leads to double-checking and mistakes on follow-up calls.
Financial information isn’t reliable. Price breakdowns, taxes and invoices are hard to interpret, and markups, fare changes and discounts aren’t visible. Agents can’t easily calculate refunds, which creates rework, escalations and risk to revenue.
003
Making sense of the interviews. Pain points from agents and the service portal team, grouped into themes such as scattered customer data, fare calculations and payment refunds.
Watching how agents actually work
In interviews, agents suggested solutions, but these were often shaped by their own workarounds. A fix that suited one agent might not work for another. So I also went through hundreds of call recordings over two weeks, to see how agents actually worked.
The recordings confirmed most of the problems, and showed where the time actually went. In most calls, agents spent the first 2–3 minutes reading through the notes to piece together the booking. Roughly a third of handling time went on checking notes and other systems, and working out prices by hand. Every change or cancellation I watched involved working out a price difference by hand, because agents didn’t trust TSA’s numbers, and a typical change request meant moving between 4–5 systems: TSA, the GDS, Voyager, airline portals and admin tools.
From there, I defined the opportunity areas we would measure success against:
At-a-glance booking comprehension
A trusted, chronological booking history
System guidance for complex, high-risk tasks
Fewer breaks in workflow across tools
System-supported work instead of manual workarounds
Financial clarity and confidence
Many of these depended on how TSA’s backend and data were structured, so this couldn’t be only a UI refresh. The product manager confirmed backend changes were possible if needed. We started small, with hotels as the first slice, because flights have more complex data layers.
004
Prioritising the opportunities. A forced ranking of six opportunity areas by impact and confidence. At-a-glance booking comprehension came out on top.
Mapping the redesign. Flows for the overview, itinerary, notes, emails and bulk cancel and confirm, worked through screen by screen.
The price breakdown
The price breakdown was the fix agents asked for most. When an agent cancels a flight in a booking and adds a new one, TSA adds both together. If the original flight was $100 and the new one is $120, the customer owes $20, but TSA shows $220. Agents work out the difference by hand while the customer is on the phone. With markups, discounts and gift cards, it gets complicated quickly.
I met with the BAs, the product manager and the finance team to understand how pricing worked. Each had part of the picture, and no one had a complete answer.
I pushed back on treating this as a UX task, because it needed wider discovery into how the pricing data worked. The product manager’s view was to mock it up and fix issues along the way. We tried that, but every round of mock-ups uncovered more problems, and we kept going in circles.
005
An agent’s screen mid-call. From the call recordings: the booking, phone system, roster and command line open side by side, with details copied between them by hand.
Pausing the project
At the time, our UX team was four designers covering the whole enterprise (it’s since been cut to two), and this was taking most of my time without moving forward. I took the issues to the Chief Digital Officer and made the case that TSA needed discovery and groundwork at the data and backend level before any more design work.
If we refreshed the interface first and the backend was fixed a few months later, the design would likely need to change again. There was pressure to keep going because of the time already invested, but I held that position, and senior leadership paused the project.
006
What the project delivered
The redesign didn’t ship. The project delivered:
A validated understanding of agent workflows and pain points
A clear definition of what TSA should and shouldn’t be responsible for
A research-backed list of problems
A prioritised roadmap of opportunities
Design principles based on how agents actually work
Executive agreement on the platform’s structural limits
It also stopped further spending on a redesign that wouldn’t have reduced handling time, and put TSA’s data problems in front of senior leadership.
007
One of the research findings. Agents rely on manual workarounds, like notes, PDFs and copy-paste, to make up for gaps in TSA.
What happened next
In Q4 2026, TSA was picked up again, this time without UX on the team. Engineering is using AI to build it, with my research and concepts as the starting point.
The concepts were never signed off. We paused precisely because no one had the full picture of how pricing and booking data worked, and those questions are still open. So I’ve been clear with the team that the mocks are a direction, not a spec, and pointed them to the open questions that need answering before anything is treated as final.
008
Reflection
I don’t see this project as a failure. The most useful outcome was showing that the interface wasn’t the main problem, and getting that in front of the people who could act on it.
Next time, I’d check how the underlying system and data work before agreeing to a screen-level brief, and raise it sooner, before spending rounds on mock-ups. It also taught me to label exploratory work clearly. When a project pauses, unfinished concepts can quietly become the spec, so I now mark them as exploratory and list the open questions alongside them.
009
