TUI
Designing for Operations: turning a complex operational workflow into a successful user experience
2024-2025
Product design, UX researchI
When TUI acquired Musement, two companies came together, and so did their tech stacks. The result was 4+ legacy systems that Operations teams had to juggle just to keep experiences bookable and available.
The answer was Nova: one platform to rule them all. My job was to make sure it actually worked for the people running operations every day, not just the people building content.
After the rework, the Operations team saved an average of 1 hour of work per day, eliminated overbooking, and stopped relying on Excel to get the job done, with a satisfaction rate of 4.1/5.
Problem
Content workflows and Operations workflows look nothing alike. If content creation is a Charmander, Operations is a fully evolved Charizard: bigger, more complex, and a lot harder to design for.
Specifically, Operations needed a way to set a limiting factor on the availability of multiple experiences at once, what we called shared allotments. Picture a catamaran tour and a catamaran-tour-with-pickup that are really the same boat: book one, and you're eating into the capacity of the other. Or two completely different experiences that both end with lunch at the same restaurant, which only has 50 seats. Without a way to model that shared capacity, teams were tracking it by hand in spreadsheets, with all the overbooking risk that comes with it.
If Nova couldn't solve this cleanly, Operations would keep one foot out the door: patching gaps with Excel and legacy tools instead of trusting the new platform.
Goals
The ultimate goal was making sure Nova actually responds to the needs of the Operations team.
I defined retention as the north star: success meant Operations never had to leave Nova to complete an action. Every workaround, every trip back to a spreadsheet, was a signal that we'd missed something.
Together with the team, we set a shared definition of success:
Operations can ensure accurate availability management across different experiences
Overbooking of shared resources is avoided
Usage of external tools (Excel, etc.) is reduced
Setting up a shared availability is faster than with legacy systems
The shared availability logic integrates with the existing product logic
The feature performs consistently under expected data loads
Jump to the results
Process
Because this was a domain none of us fully owned end-to-end, the process leaned heavily on the people actually doing the work:
In-depth interviews with Operations, to understand the real workflow, not the one we assumed existed
Workshop with Operations for discovery, mapping out where shared capacity actually breaks today
Wireframes, tested with Operations, to validate the logic before touching visual design (I never expected to be building a POC in Excel…)
UI/UX design and development handoff, refined again with Operations
Discussions with backend & architecture, and a dedicated workshop with the tech team, to pressure-test technical feasibility
User tests with Operations on the final flow, before release
Prioritisation mattered here: rather than trying to redesign every operational workflow at once, we picked where to start based on impact and leverage for future improvements, starting with contracts and allotments, since almost everything else depends on getting availability right.
Workshop outcomes
Proof of Concept built in Excel
Final deliverables
Results
The resulting Allotment planning screen lets Operations define, per experience or option, a date range, languages, zones, and a day-by-day capacity. It replaces what used to live in ad hoc spreadsheets with hand-maintained formulas.
Excel is no longer used to complete the shared allotment flow
No overbooking of shared resources
The Operations team saves an average of 1 hour of work per day
Satisfaction rate: 4.1/5
A solid, documented logic that supports further platform development
Learnings
This project was intense, but it taught me a lot along the way. Here's a small selection of what stuck.
Never underestimate or oversimplify the complexity of a domain
Users are the experts in their field
Success metrics need to be defined collaboratively
Prototyping needs to serve the purpose of having a tangible artifact
Technical feasibility strongly impacts UX feasibility
Alignment with architecture and backend is as important as alignment with frontend
Involve the tech team as early as possible
