Egencia, a Travel Management Company or TMC, is a subsidiary company to the Expedia Group. The original application was launched in 2012 as a trip itinerary companion to the desktop ecosystem. Over the years the needs of the business, as well as the users, called for more functionality inside the app that aligned with the desktop. This yearlong project documents the process that I took to gather data, align stakeholders and create a strategic testing plan for the alignment of our core products.
CLIENT | Egencia
ROLE | Lead Product Designer
PLATFORM | iOS and Android
TIMELINE | 12 Months
High Fidelity Mockups
A/B Testing Strategy
Design Thinking Workshop
The current desktop product has functionality for multiple users with a variety of permissions and workflows, but here are the 4 main user roles:
Self Booker — A person who is shopping for their travel and will have their company reimburse the cost.
Travel Manager (policy)— A person who sets up travel policies and negotiated rates for their company so that travelers stay within the company's budget.
Trip Approver — A person who looks over a traveler’s trip to make sure it is in line with the company’s policies and budget before approving the transaction.
Travel Arranger — An authorized person that shops on behalf of the traveler (end user) and completes the bookings.
The mobile app was originally built for Self Bookers only, and as of last year, we have brought in limited functionality for an Approver.
With the rise of business needs on the go, the Egencia mobile app has been tasked to absorb as many of the desktop functionality as possible. In particular, our power users, like the Travel Arrangers and Travel Managers are asking for more in-app features.
The key problems that need to be solved:
How do we fit all the new features/user types into our apps with the current navigation flow?
How can we better align with the desktop platform to create a branded experience knowing that 82% of our users make buying decisions based on both the desktop and app shopping?
How do we stay true to each operating systems’ aesthetics so that the app feels native?
How do we utilize Egencia’s current AB testing strategy to our advantage with rolling out these changes?
The Problem Statement:
As a mobile user who makes my purchasing decisions based on both the desktop site and the mobile app, I expect my experiences to be as similar so that I do not have to learn new navigation/shopping patterns and I can purchase my travel quickly and efficiently.
The iOS app utilized bottom navigation as is customary, but the app had already exceeded the 5 CTA max.
Android utilized the side drawer but was quickly becoming cluttered and overwhelmed with the 12 CTAs and counting.
Both operating systems needed to reshuffle and categorize the hierarchy of user flows before adding more user roles and ingress points
82% of our app users utilize both the desktop and their mobile app to make purchasing decisions
The app is no longer its stand-alone product, but an intricate part of the Egencia buying cycle
The two drastically different navigation and layout of the two apps made feature parity almost impossible
When releasing new features, in order to gauge customer sentiment and testing, the experience and timing needed to be on the same schedule
The Android app was closest to our desktop responsive view, but 80% of our mobile users are on iOS.
The Android app had the closest parody with the desktop counterpart
The iOS app was designed in a vacuum and had little continuity with the Android app or the desktop user experience
The Android app hid key navigation paths in their side drawer
The iOS app hit their maximum allowance for ingress points on the bottom navigation
Align both iOS and Android UI as closely as possible with exceptions for system standardized elements
Swift language does not follow the same syntax as Android and desktop
The desktop product follows a UI similar to Material Design
To stay in parody with Android and desktop, the iOS development team would have to create custom code for the new UI changes
We needed a design language that could be represented universally for all platforms
Representation of our direct competitors in my research was key in stakeholder buy-in. In the TMC market, viewing any details of an application requires a secure login provided by the user's company. I had to rely on App Store screenshots and friends who felt comfortable sharing their private information with me.
In order to provide a well rounded competitive audit, I surveyed applications in and outside of the travel industry. Conducting this extensive survey solidified my hypothesis that unified navigation was common among large brands with a global reach.
Some of the more complex companies, like banks and e-commerce giants, had a universal design language for all interfaces regardless of the operating system. The other commonality was the use of a side drawer on iOS and responsive web.
I conducted a more in-depth teardown of two applications that helped determine this navigation strategy as well as helped with the design of the car shopping path.
Read the full article here on Medium.
Convincing the iOS development team to stray from the Apple generated components and adopt custom components was met with some pushback. Creating team buy-in and support for this large overhaul was important, so I held a mobile team meeting where I went through the North Star vision and shared all the research and data that I had been collecting. Much to my surprise, the biggest resistance was to the idea of the side drawer (hamburger menu). In the meeting I had all the iOS developers take out their phones and start to go through their top 5 apps. Once they realized that any app that was not a native iOS app (like Mail or Photos) utilized the hamburger menu, they got on board.
To quickly create digital iterative design ideas, I utilized Invision Freehand. My Android team sits in the Chicago office and my iOS team is located out of Seattle. With the team split between timezones and offices, it was important to have a digital way to communicate quick design decisions that would otherwise take place on a physical whiteboard in the office. During meetings, I could control the screen and have the developers follow along and help me work through possible roadblocks in real time.
The most complex use case was the transition of bottom navigation to the side drawer for iOS. The white-board exercises helped both the developers and the product managers understand at a high level the architecture of the change.
Old App Navigation
New App Navigation
Now that we created space for the adoption of more users and use cases, we needed to unite on the next steps. I facilitated a half-day Design Thinking workshop for the product stakeholders to brainstorm and define our strategy.
For the full workshop outline and outcomes, you can read my Medium article.
I have started to work closely with the designer and product team who owns the desktop landing experience. We have created north star visions of where we see our products aligning. Over the next year, our teams will work closely on a testing strategy that validates our observations and hypothesis.