Etta Travel App
New branding, new requirements, and a new modular architecture for scale.
When I joined Deem, they had just wrapped up contracts to be the travel platform for Apple employees worldwide.
With this, Deem would design, build, and co-launch a private-label version of its upcoming app, Etta. Working with Apple’s Information Systems & Technology team, we would need to research and integrate specific requirements and integrations to best serve Apple and the needs of their employees.
To make things slightly more complicated, the Deem mobile team had already spent months building a native iOS application utilizing designs from an agency called Fantasy. And, in that span of time, a different agency, Mucho, had been utilized to create a completely new brand update and product name.
Company: Deem + Apple
Role: Product Design Lead
Dates: June 2020 - Dec 2020
Responsibilities:
Design Strategy & Leadership
Research
Journey/Experience Mapping
Information Architecture
Concepts & Prototyping
Stakeholder Management
Presentations
The Goal
Determine and understand Apple's travel needs, then work with our design and engineering team to implement an architecture capable of being white-labeled to carry both the Etta and Apple brands.
Thinking about travelers' needs
Traveler Journey Map
One of my first steps working with Apple was to create a high-level customer journey map, partly to better understand the full picture for travelers and partly for the Deem teams to begin thinking about jobs that exist outside their current primary focus of booking.
The full experience for the traveler begins as soon as they’re onboarded into their company. For many, especially those that aren’t required to travel as part of their job, the question of “how do I book travel?” only comes up the moment they’re required to do it.
I believed that we could seize opportunities outside the act of booking that would make travel more enjoyable and stress free for employees when their time came to travel.
The map also highlighted areas where other apps or services were already successfully being used by travelers. Unless there was a real benefit or opportunity for us to create efficiencies for the traveler, we shouldn’t compete with apps or services that already had strong user loyalty.
Design Audit
The Apple Information Systems & Technology team wanted to make sure that we followed Apple UI Guidelines as much as possible, even assigning an internal UX stakeholder to act as a guide.
I knew we had to perform some serious iterations on the designs handed over by Fantasy, so we needed to ensure we could make some concessions for Apple without allowing them to determine the direction of our platform.
To create space for us to work within their requirements, I met with the team to go over Apple’s suite of apps...with the purpose of illustrating the differences and liberties each app team takes within their guidelines.
The team was somewhat surprised to see the differences between the apps when viewed together...to the point they joked they’ll never be able to unsee the differences. Lucky for us, the audit relaxed their need for control and gave us the room we needed to work.
Travel App Landscape
We established clear patterns within the consumer travel app landscape, which clearly focused on booking the next experience rather than the upcoming trip.
For the app home screen, primary space at the top directs the user to the type of booking, while remaining space is used for messaging, safety guides, or trip planning.
The Apple team was pushing for a path that required a user to search for a destination first, explore information about that location, then book travel from a destination page.
Though an interesting concept, the path slowed booking and was heavily reliant on Apple and/or Deem having a massive database on locations through a 3rd party.
Further investigation revealed the interest was mostly driven from a unique process within Apple. Apple required employees first to obtain approval to the destination by a 3rd party - then the booking could occur and was automatically approved. This detail informed us to take a modular approach, where Apple could incorporate custom modules into the app for special purposes.
Exploring Concepts
We went through a large number of layouts and concepts for every page and component of the app, many based on Apple UI patterns and their audacious plans to include content from an internal travel wiki.
City guides, articles, and support documents were all part of Apple’s custom CMS built by a 3rd party. As we dug into the content, we realized that much of it was outdated, unfinished, or repetitive.
To keep us from spending too much time parsing and sorting out their content issues, I began looking for an alternative CMS, eventually landing on Sanity. Now we were able to assign responsibility back to Apple for content curation, with the bonus of utilizing the new CMS for our own branded app.
The News and Support sections were all driven by Sanity and customizable by each company...two of several new features that were born through the partnership and available to all customers.
Results & Final Outcomes
In the end, having Apple as our most valued customer caused lots of internal debate between what concessions we should make for Apple and what might be considered positive or negative outcomes for the thousands of other customers we had on the platform.
Once we made our architectural changes, Apple’s contract allowed them to add custom modules and features in their own binary that we would never build independently. This meant we would need to design our navigation, layouts, and modal structures to coincide with their custom additions and requests.
The back and forth with their internal stakeholders was a great experience for me and the team, consistently pitching, iterating, and negotiating to arrive at a design that made everyone happy in the end...most importantly business travelers.
The partnership continues to progress as feature requests are planned.
