The Tripadvisor Design System

Context

Systems and processes have always been a part of my DNA. In fact, as mentioned within My Story, this passion started at a young age. Throughout my career and into the present day, I have been passionate about creating streamlined approaches to the product development lifecycle and feel compelled to improve on inefficient processes. So when the opportunity finally came for Tripadvisor's first foray into creating a design system of its own, I thought I simply must be a member of that team. It would be the first step of a multi-year journey into the wild world of designing a system that would power Tripadvisor's future.

The problem

Historically, there was a siloed approach to product development across business lines. As a result, A/B test wins were rarely implemented across business lines causing design and tech debt to accumulate. In addition, a fractured UI and UX across business lines became a broken and outdated approach to development which caused tech debt to collect as well. This combination of factors negatively affected travelers' ability to plan the perfect trip confidently.

The approach

There were already a few wheels in motion to address the consistency issues for the organization and the traveler. One initiative was a refresh of the brand and its assets. The other initiative was to build a new tech stack from the ground up, which leveraged a server-driven UI model with a shared set of components that would fundamentally change the TA tech stack. 

Since the native platforms had a lighter effort to re-platform than the web platform, the initial plan was to prioritize this new native experience first, then scale to the web. The stage was set for the Tripadvisor Design System (TA DS) to power the expression of the new brand through a consistent system of UI via our server-driven UI app presentation layer. 

My role was to work with a small team of product designers, and together we would figure out the best way to scale the native system of UI to the web platform, which would all live under the TA DS umbrella. At the same time, I helped push forward a change in our product design toolset that would focus on collaboration and process efficiency. After being introduced to Figma (shoutout to Osub Lee 🤯) and then dabbling with the tool for a few side projects, it was clear to the team that the entire organization needed to adopt this tool for our new way of working. So we quickly moved away from Sketch+InVision+Zeplin to exclusively using Figma as a replacement for all three. One of Tripadvisor's company values is "Speed Wins" and using three tools did not fit that value, especially when Figma was already good at replacing all of them in the cloud and was always up to date.

The plan was to split the TA DS into three different systems where all UI components, templates, and documentation would live. 

• Global DS: the base file which contains brand standards and global components that appear on all platforms
• Native DS: contains native-only components
• Web DS: contains web-only components 
  

We created three separate libraries so that the native experience could move independently from the other design system workstreams and not be inhibited by a slower-moving web platform.

The outcome

The Design System Team established a process that started in the Native DS for the native platforms and then graduated components to Global DS as it made sense. Our mission was to prioritize cohesion, accessibility, and reusability across the system. My scope was to vet and document the initial components from the native platforms to see what adjustments needed to be made so that they would work for web use cases. If successful, I transitioned those components to the Global DS, but if not, they remained in the Native DS. At the same time, I worked with the web platform to create and document components specific to it. As a result, the web platform moved slower because it contained more use cases than native.

Before long, the Tripadvisor Design System Team created a centralized repository that included onboarding documentation and documentation of the system itself. We also developed a process to contribute to the system and initiated office hours to help other teams use the design system. As I became the resident Figma expert, I recognized that I could help my fellow designers become better at using the tools. So I started a series of internal tutorial videos labeled Figma University to help everyone on the team be proficient with Figma and the TA DS.

Tutorial Short: Prototyping with Master Links

Tutorial Short: Using Overlays in Prototypes

Tutorial: Copying element properties in Figma

Figma Config 2021 keynote recap

Tutorial: Parent and child multi-select in Figma

Next steps

While the Tripadvisor Design System is only a few years old and still in its infancy, it's incredible the progress our small team has made during that time. I have helped the TA DS grow from concept to implementation while at the same time watching the team learn new tooling, new tech stack, and new ways of working. As a result, I realized that communication, persistence, and continuous evolution are critical to a design system's success. It can not will itself into existence, and it can not be rigid in how it is governed. A design system is meant to evolve and grow with an organization. It requires continuous maintenance to remain a relevant asset, but therein lies its beauty.

The next phase for the team is to evolve our implementation and add an automated approach to managing tokens to quickly expand to more properties that remain in our backlog. I am also looking into how we can introduce motion design into our assets and documentation.