As the company's first dedicated internal tools designer, my primary focus was to make UX improvements on the internal tools for our service team, The Wombats. I was able to redesign the internal console to tackle the diverse set of problems that the Wombats faced every day.
However, like many startups, the service team filled in for feature gaps on the user-facing product. The console redesign helped them spend less time finding needed information to be effective travel agents, but were still underwater yielding customer requests as a stop-gap for missing features, especially those relating to flights.
I set out to design a set of power tools that worked within the console. The infrastructure that we build for these tools will set the foundation of other product teams to create user-facing features so that we don't need to rely on our MVPs anymore. My process was as follows:
Interviewing Wombats on how they process flight modifications
Identifying which modification requests were the most common
Running a card sort to understand the mental and technological models of these modifications
Designing user workflows for each type of modification
Iterating and testing multiple concepts for each set of tools
Working with the engineering team to understand the limitations of our back-end infrastructure and descoping as needed to create lean, high impact tools
My PM and I ran a couple of anonymous wombat surveys to determine the most significant pain point in their day-to-day jobs. There was a clear trend in the results: Editing bookings were the most commonly requested feature by far both times we ran the survey.
"Editing a booking" refers to reflecting changes such as rebookings, add-ons, and cancellations in our internal tools and user-facing product. Many of these changes are processed and managed manually by the Wombats using the Amadeus Global Distribution System (GDS), and then manually re-entered by the Wombats in our systems.
Wombats specialize in using the Amadeus terminal to make changes to bookings when users are not able to self-service on the platform.
AltexSoft has an excellent video that explains the history and functionality of GDSs if you would like to learn more.
The Amadeus GDS terminal is a tool that travel agents use to book travel. Its technology has not changed very much since the mid-1980s; it remains rather complex, and the learning curve is quite high. We have a few dedicated wombats who are versed in using Amadeus to handle customer requests for flight modifications as needed.
Because bookings are modeled after (arguably robust) data structures that provide travelers the most accurate information about their travel plans, allowing someone, even a highly trained user like a wombat, to be able to edit a booking like you could edit a form could have implications on how that information is displayed and updated to the end-user.
We used OptimalSort to facilitate a moderated open card sort.
I set up and ran an open card sort with Optimal Workshop to understand what different booking modifications might look like when grouped in a user interface. I acted as an in-person moderator to facilitate discussion.
Some interesting takeaways :
Archiving/Hiding a booking is not considered to be a true modification or edit.
Cancellation of a segment is seen as a type of “flight modification,” while canceling a booking is not by more experienced wombats.
I designed a user flow that our wombats, and ultimately, the end-user, could use to process flight modifications.
This was the first time our organization used card sorting and user flows as research methods, so I put together a slideshow summarizing the study setup and findings for an engineering and product all-hands meeting.
I hosted a brainstorming session with my PM and engineering team to determine which parts of the flow we could build first to impact the Wombats' work significantly. Three features in particular stood out:
Add-on luggage and seat upgrades: they are the most clearly defined booking modifications.
Flight segment modification: the most common modification request for wombats and travelers.
A credit management system: the most manual part of the booking modifications for the wombats
See brainstorming session with our engineering team →
We decided on a credit management system because it would be the least risky to build. The other options touch the booking models of the user-facing product, which would require other different product teams to deprioritize other features they planned to build to support our work.
When a wombat processes a flight change or cancellation for a traveler, the airline will issue a credit if there is excess cash. Because our product's booking models had no way to store or manage credits, wombats held them separately from our system in an enormous google spreadsheet.
I hosted a design kickoff session with our engineering team and few wombat stakeholders to define what elements would be necessary to build this feature.
Designing the credit system was relatively straightforward because it was modeled after the functionality of the Amadeus GDS. I validated the design with a quick round of usability testing.
Here are some fascinating things I learned about credits in the process:
Credits are "owned" by the traveler. Even if someone else pays for a booking, only the traveler for that booking can redeem that credit for later use. We needed to consider the implication for displaying these credits to the traveler; the person paying for the travel may not want the traveler to use a flight credit for non-business travel.
It is an industry-wide standard for travel credits to expire one year from the date of issue unless otherwise specified. Therefore, we could set a default expiration date for the credit, and design features around these expiration dates.
Now that we had a robust internal system to track credits, we could surface this information to the user-facing product. Credits were presented to the user in two different areas of the product:
A monthly credit email
A report for travel credits
We released the credit management feature in February 2020. It was a welcome addition to the wombat's internal toolkit; they no longer needed to process and add credits to a google spreadsheet manually. Our team easily imported over eight hundred credits into our system, and any new ones could be added in a matter of seconds.
The COVID-19 epidemic hit the United States only a couple of weeks later. Flight cancellations skyrocketed, which meant that thousands of credits were being issued by airlines to our customers. By the end of March, our system hosted three thousand credits, with a total combined value of over 1.2 million dollars.
Credits were only one of the power tools we identified in our study, and building a robust credit system was a multi-sprint project. Since then, we've built cost events, a system that allows wombats to generate receipts for ancillary purchases.
Next on our horizon is the ability to make flight exchanges without relying heavily on our wombats. Check back to see how this project is doing!
