Back-end Interface Design
for Travel Toogle
Designing the engine
behind every traveller
Travel Toogle needed a backend management system capable of handling the full operational load of a travel company. Employee management, customer itineraries, payments, refunds, and voucher generation all within one coherent interface. This project covers the employee-facing side of that system.
What the data
told us first
Every major design decision was grounded in research. Both primary work done directly with travel operations staff and secondary investigation into the broader industry landscape. Hover any stat card to see the full finding and source link.
Post-pandemic digital adoption pushed the global online travel sector into a sharp recovery curve, making backend operational tooling a critical investment area for any travel company trying to scale.
Statista Travel Market Report →Fragmented booking workflows were the single biggest driver behind building a unified backend for Travel Toogle. Agents were copying data across spreadsheets, email threads, and booking platforms simultaneously.
Skift Research 2022 →Forrester Total Economic Impact studies consistently show significant productivity and error-reduction gains when internal tools are properly designed for the people using them, not just for feature completeness.
Forrester Total Economic Impact →Post pandemic recovery shifted the industry focus toward making sure internal teams could operate efficiently at scale again, validating the case for investing in a dedicated backend system.
Phocuswire Industry Survey →The consumer-enterprise UX gap is a major motivation for investing in backend design. Users have high expectations shaped by polished consumer apps and internal tools consistently lag far behind.
Nielsen Norman Group 2021 →This finding shaped the information hierarchy across all modules. The most critical data surfaces first, with deeper details accessible on demand rather than displayed all at once.
Baymard Institute Dashboard UX →Context switching between tools is one of the strongest arguments for a consolidated backend. Every time an agent switches application to complete one booking, the risk of data entry errors climbs significantly.
McKinsey Digital Operations →Customer expectations shaped backend performance requirements directly. Real-time update workflows and fast data retrieval were non-negotiable constraints on the itinerary management module design.
Google Travel Trends 2022 →The most important secondary finding was that backend UX in the travel industry had a significant unmet opportunity. Mature platforms like Amadeus prioritise feature completeness over usability and smaller operators have almost no good tooling available at all. Travel Toogle had a real chance to build something meaningfully better than what existed.
Every screen,
every flow
Three major operational flows, each presented in the order an agent actually works through them. Select a flow, then click any screen thumbnail to read the full annotations. Every description matches the actual screen content.
The Create Itinerary flow follows the natural order an agent works through: open the module and review booking context, then build the trip service by service - flights first as the trip anchor, then visa documentation, accommodation, tours, transfers, and miscellaneous services. Traveller documents are collected before the full itinerary is reviewed, with vouchers generated across all confirmed line items. Destructive actions like line item deletion are protected by confirmation dialogs at the end.
Itinerary Module - Empty State
The Create Itinerary screen is shown in its initial empty state with three collapsed section tabs at the top: Booking Description, Traveller Details, and Commercial Details. The left sidebar displays the complete navigation structure for the Create Itinerary module - line item type tabs including Airticket, Visa, Hotel, Tour, Transfer, and Misc, followed by Customer Documents, Generate Vouchers, Cancel Trip, and Back. The main content area below the section tabs is entirely blank and white, indicating no booking summary data is currently expanded and no line items have been entered in this view.
This is the first screen an agent sees when they open the Create Itinerary module for a booking - the clean empty state establishes the starting point before any services are added
All six line item type tabs (Airticket, Visa, Hotel, Tour, Transfer, Misc) are visible in the left sidebar from the outset so agents can begin entering any service type without a prescribed order
Booking Description, Traveller Details, and Commercial Details tabs at the top are collapsed initially, allowing agents to expand context as needed without cluttering the primary workspace
Generate Vouchers and Cancel Trip are visible in the sidebar immediately, ensuring these critical end-of-flow actions are always accessible regardless of where the agent is in the build process
100+ screens covering all flows, with interactive transitions and edge case handling throughout.
Mapping the whole
before designing the parts
The front-end data flow diagram was the first deliverable, establishing how information moves between the customer-facing product and the backend system before any screen was designed.
The reasoning
behind the choices
Every meaningful decision in this project had a reason grounded in research findings, established UX principles, or direct feedback from the operations team. Click any item to expand the full rationale.
Navigation is structured around operational modules rather than a flat sidebar. This came directly from the card sorting exercise, where staff grouped tasks by workflow context rather than by data type.
Research comparable to NNG findings shows staff who organise by workflow context complete tasks 35% faster than those navigating flat link lists. The mental model match reduces orientation time on every single session.
What this project
produced
Drawing the connection between the frontend and the backend before designing any screens gave the whole project a shared reference point. Every time a question arose about what a screen needed, the data flow diagram had an answer.
Spending two weeks on competitor analysis before wireframing meant the design never had to revisit foundational structure. Decisions could be grounded in real-world comparisons with known systems, making stakeholder review conversations significantly more productive.
The internship timeline did not allow for moderated usability sessions on the high-fidelity prototype. In a production context, testing assumptions about navigation speed and information findability with the actual operations team would have been the critical next step before development began.
This project was completed during an internship at Travel Toogle as part of an undergraduate design programme. It represents one of my earliest large-scale backend UX projects and taught me that enterprise design requires a fundamentally different set of priorities from consumer product work. Density, efficiency, and trust in the user are the values that matter most when designing for trained professionals who use a system hundreds of times a week.
Back-end Interface Design
for Travel Toogle
Designing the engine
behind every traveller
Travel Toogle needed a backend management system capable of handling the full operational load of a travel company. Employee management, customer itineraries, payments, refunds, and voucher generation — all within one coherent interface.
What the data
told us first
Every major design decision was grounded in research — both primary work with travel operations staff and secondary investigation into the broader industry landscape. Hover any stat card to see the full finding and source link.
The most important secondary finding was that backend UX in the travel industry had a significant unmet opportunity. Mature platforms like Amadeus prioritise feature completeness over usability and smaller operators have almost no good tooling available at all.
Every screen,
every flow
Three major operational flows — Create Itinerary, Payments & Refunds, and Employee Profiles — each annotated in the order an agent works through them.
The full annotated screen walkthroughs with 100+ prototype screens are best experienced on a larger display.
Mapping the whole
before designing the parts
The front-end data flow diagram was the first deliverable, establishing how information moves between the customer-facing product and the backend system before any screen was designed.
The reasoning
behind the choices
Every meaningful decision had a reason grounded in research findings, established UX principles, or direct feedback from the operations team. Tap any item to expand.
Navigation is structured around operational modules rather than a flat sidebar. This came directly from the card sorting exercise, where staff grouped tasks by workflow context rather than by data type.
Research comparable to NNG findings shows staff who organise by workflow context complete tasks 35% faster than those navigating flat link lists. The mental model match reduces orientation time on every single session.
What this project
produced
Drawing the connection between the frontend and the backend before designing any screens gave the whole project a shared reference point. Every time a question arose about what a screen needed, the data flow diagram had an answer.
Spending two weeks on competitor analysis before wireframing meant the design never had to revisit foundational structure. Decisions could be grounded in real-world comparisons with known systems.
The internship timeline did not allow for moderated usability sessions on the high-fidelity prototype. In a production context, testing assumptions about navigation speed and information findability with the actual operations team would have been the critical next step.
This project was completed during an internship at Travel Toogle as part of an undergraduate design programme. It represents one of my earliest large-scale backend UX projects and taught me that enterprise design requires a fundamentally different set of priorities from consumer product work.