The old console was designed for personal travel in mind. Post-pivot, features were slapped on as needed and were not discoverable.
An internal tools overhaul
Adapting to the different working models of travel agents at Lola.com
Lola pivoted into business travel after struggling to find success as an AI-powered personal travel agent. The company had to quickly adapt from a B2C to B2B market by adding features that fulfilled the needs of business traveler, administrative, and finance personas.
I joined Lola at a time of rapid growth; in 2019, our customer base grew by 1,147% and became the #1 rated travel management app on G2. It only takes one glance at our product reviews to understand that our service team (which is made up of travel agents whom we lovingly know as the Wombats) is the reason why our customers loved working with us.
Now that Lola was rapidly growing, stakeholder's eyes were on the cost of service and the team's morale. The wombats were spending most of their time with a tool called "The Console," which housed customer information to provide top quality service. The only problem was that it was optimized for the personal travel app Lola once was.
I was responsible for the entire end-to-end redesign of the console. My workflow was as follows:
Auditing the current tools available to the Wombats
Interviewing and getting to know the wombats working styles and difficulties of their jobs (and how the current tools help or hinder their work)
Brainstorming low fidelity designs and prototypes
Coming up with a "North Star" design, validating it via usability testing, and
Breaking apart this design into sprint-sized chunks of work for our team, the Womgineers.
Observational studies & interviews
Being new to Lola and business travel technology in general, my PM and I constructed a series of interviews and observational studies to understand how wombats performed their duties.
Insights to note:
Because bookings can be booked on behalf of someone, the person who contacts support isn't always the same person that booked the travel and/or has permission to make changes to the booking.
If a wombat needs to provide company account support, the wombat would need to search for a user in that company and then navigate elsewhere to access company details.
Users don't always provide the correct information for a Wombat to service their needs. This requires the wombat to do a bit of digging and investigation on their end; redoing the search from the beginning to get to the information they need can be tedious.
Wombats want to "see what the user sees," but not literally. They want to see the same information the user has available on their accounts because it was simply not available in the old console.
The Wombat "Legacy" Console
Our wombats spend most of their working hours on two platforms, one being Intercom's Conversational Support Tool and the other being the "Legacy Console."
This console was built when Lola was still an AI-powered personal travel consultant. As a result, there is an assumption that the customer we are servicing will almost always be the same person who manages or participates in the travel.
The old console forced the wombats to first search for a user in order to access any information. This UX pattern was a major pain point for wombats as it was common for the person to be contacting support to be different from the person who booked the travel. For example, an employee may be the one to contact support if they need some last-minute booking changes, but only the company's administrator may have access to essential information such as payment methods.
Foundations of the "New Console"
The "Legacy Console" was not the only internal support tool that was available to the Wombats. There was a third tool that was not utilized nearly as often: the "New Console."
Despite being called the "New Console," the wombats did not see the tool as a replacement for the "Legacy Console," but a highly specialized tool for generating reports, specifically in times of inclement weather.
Wombats would enter search criteria, which would generate a list of bookings, and from there, a wombat can see a replica of the booking as the user sees it on the Lola platform. They would take these results and proactively reach out to the travelers of these bookings to offer them a way to make any changes or updates to their travel plans.
Setting the scene with a job story
Post-research, my PM and I sat down to create a job story we can use as guidance for redesigning the console.
When a Lola user contacts the support team, I want to quickly see all of their relevant information (all user-facing info, internal Lola info, travelers, bookings, trips, comms, notes), so I can provide them with timely service.
A few guiding design principles
I worked together with my product manager to brainstorm a few preliminary designs. Here were the design principles I kept in mind while brainstorming UX schemas:
Wombats are expert users and can be trained to use the product effectively. Therefore, while information should still be organized and straightforward to access, it's okay to condense it.
We should not create prescriptive user flows. Because wombats service such a diverse set of problems, there should be multiple entry points to find the information they need and various ways to navigate to different areas of the console without having to "restart the search."
We can provide architecture on how to group information, but we should not be afraid to have the same information in multiple places. For example, payment details such as the payment account holder and payment method could be available on both a user's account and on a booking details page.
Time for usability testing
I put together a prototype to quickly set up a series of usability tests with six wombats. Ideally, we would have a dedicated researcher to assist, but as the only designer with research experience on my team, I had to run these sessions myself. Fortunately, my product manager and engineering team helped me as observers and note-takers!
My main concern was that the wombats were so accustomed to the old console that they would have difficulty understanding the new user flow. Fortunately, the team was rapidly growing, and there was a clear distinction between "pre-pivot" wombats who "grew up" on the old console and "post-pivot" wombats who were still learning the ropes.
While some of the pre-pivot wombats could not complete all the tasks on the first try, all of the post-pivot wombats could complete the tasks without any problem. Knowing this made me much more confident in moving forward with the design we tested.
Determining The "V" in MVP
We were able to test and iterate on the design until we reached a "North Star." From there, we determined which elements we needed to build to stop supporting the old console.
My PM, Engineering Manager, and I hosted a kick-off meeting to determine which console elements were:
Feasible to build in a reasonable time frame and,
Would be viable enough for the wombats to gain value from
I took the North Star prototype and went through each section and interaction I designed. Meanwhile, the engineering team broke down and estimated each part of the design into sizable Jira tickets. My PM and I looked at each ticket and determined which parts of the console were necessary to build to ensure that the wombats could successfully serve their customers, and created an MVP prototype for the engineers to reference.
What's next: new features and where to place them
Our engineering team released new features for the new console weekly, and the wombat team quickly noticed that the new features greatly improved their experience. Eventually, there was a tipping point of new console features, and all the wombats were now using the new console regularly.
We shut down the old console in December 2020, but this did not mean we were finished; we were just able to ship the MVP. Since then, My PM and I have been running a series of surveys with the wombats to see which features we need to build next. Many quality-of-life improvements and new features are still on our product roadmap.
Overall, console migration was a huge success; because the information was laid out in a structured manner, it was easy to visualize where any new feature would live. Even now, I regularly receive feedback on where new features can live in the console from our wombats.