Lessons From the DesignOps Journey of the World’s Largest Travel Site

Eniola Oluwole
Chief Strategy Officer, Velir

From the DesignOps Summit website:
Launching a design operations practice is always a challenge, but when you’re the world’s largest travel site, with 490 million monthly visitors and content in 70+ languages, the complexity can seem insurmountable. In this session, Eniola Oluwole will share TripAdvisor’s journey from groups of disconnected design teams with very little process, multiple style guides and no standard toolset, to an integrated organization with a thriving design operations practice. Attendees will learn how to communicate the value of a design ops practice, evaluate design management tools, engage their team in the process and identify the right time to hire dedicated support.

He is going to talk about Trip Advisor’s journey into DesignOps. It’s a bit of a redemption, a coming of age story, and a change management story. It’s important to understand people and how to motivate them. And important to understand the culture where they work.

He has about 20 years of experience in UX and strategy work, the past 9 have been spent in leadership roles. About 95% of his time has been at an agency or as a consultant. When working with an in-house company, he didn’t think beyond the hand-off. The focus of the story today is around design systems.

For Trip Advisor, design systems was really the catalyst for DesignOps. A major design system serves as the source of truth for eadling wihth topics such as localization, and governmental rules regarding privacy or shipping.

70-75% of travelers globally use Trip Advisor. They think of themselves as a technology platform vendor. There is not one website – rather, as nine major business units around how people shop for travel. They are using Machine Learning, lots of experience in that space due to the volume they’re dealing with. When he arrived, they had been without a design leader for a year and a half. Peeople were working in silos, and not thinking about the end-to-end experience for consumers.

In their business, a .5% increase in conversion means a $2M increase or decrease in revenue. That focus on small features made it hard to focus on the experience more holistically. When he joined, he found a significant disconnect between what he expected and the reality:

The overall design landscape is such that each team created their own design system. There was no centralized governance or communication around design. If it had some green in it, it was Trip Advisor. There were 20+ Guides and pattern sets.

This created a cultural experience where everyone did what they wanted to do. People were fine with building up those silos of indifference / uncaring.

The problems:

• Teams were not collaborative – they didn’t talk, didn’t care what others did.
• There was a lack of efficiency and scalability, Processes didn’t allow them to work with other groups. Working across sites required navigating multiple proesses.
• Culturally, people were highly resistant to change. There were risks associated with large changes. If ideas were too big, they wanted to dial it back to the smallest unit of that idea that was proven profitable.

He realised he needed to assess what they were doing now, define a new process, he had to organized existing tools and people around that new process. ANd he had to find a way to make them care.

Using a user-centered design process, he talked to designers using their design system. They wanted to know what the right pattern to use, and when. And they wanted the latest version from optimization and testing. Developers wanted their own instance so they could see the patterns without disrupting things more broadly. They also wanted to know what was official, and who made the decision so they could negotiate it.

He came up with a set of design principals:

It needed to be one place, accessible to anyone. It needed to be easy to update, as well as easy to search and navigate. And they needed clear accountability.

They assessed various platforms for the system:

They looked for a solution that fits most of their needs adn their work culture. They ended up breaking design system into two major buckets. One was the pattern library, and the other was a Story Book. The devleopers used this as a living record of what was on the site. The goal was to have a 1:1 relationship between the library and the design system.

McKinsey helped them developed a governance model, so that tehre were clear boundaries around what patterns cound or oculd not be disputed, what threshold, etc,

He established a 5 month timeline:

Their interim solution was to use Confluence to manage their design system, because everyone was already familiar with it for managing product specifications.

All the content was centralized there. They called it The Great Cleanup. They had patterns that were 10-15 years old and brand new ones. They decided that if the pattern was off brand, if wasn’t not best practice, if it tested down, they would delete and forget it. If there was research done, if it tested up, they kept it. If there were two patterns we did A/B testing, or made a decision about which one best met their goals.

Making people care. There were incentives (mostly cash). The company’s motto was ‘speed wins’, so they aligned with that messaging. For engineers the communicated that patterns created efficiencies, because you only have to build it once and re-use it. They gave cash prizes for best overall pattern, best research … and there were monthly cash awards for people who met those migration goals.

He knocked on doors, kissed babies and … it didn’t go well. The things that did go well were that they broke down some of the silos around design. It also helped to start conversations with engineering about what good outcomes could look like. These conversations helped people undestand that design is not just about skinning screens, but also how to be efficient and sucessful as a business.

Four things that went wrong:

• Lack of communication. People weren’t clear on status, whether changes were made, or in general what the processes were.
• What is in the library didn’t match the website. Seeing things that were live that didn’t match the library – they had to have ways to handle those situations,
• People didn’t have a sense of ownership after the incentives stopped, so things weren’t updated.
• There were inconsistent levels of craft and fidelity. Some people put in a screenshot with a brief description, but others’ entries were more robust.

When you are the cheerleader for a large organizational change, there is a feeling of shame or failure when it doesn’t work. And people will talk about that in a meeting – whether you are there are not.

But that’s normal. When you launch something, it’s not a sprint with a clear end. You keep iterating. You have to do the thing first – get something out there. But once it’s out there you can make it better. He realized he had to be ok with failure, and just fail better the next time. Thinking about change management, design ops … the goal might be to create a design system or a career ladder. But it’s not done once you hit that goal, because the organiation is always changing around you.

He revisited his plan, and committed to re-assess, re-define, re-organize, and keeping them caring.

He started by launching a survey to get feedback on how they were using the design system, and what the challenges were:

From the survey he learned that people used the system daily or not at all. People who were using the system regularly wanted to find patterns but couldn’t. They also felt that designs were self-evident, and that the documentation and rationale was getting in the way of the use-cases. In reality, most people re-used old patterns.

So, they made a number of changes including providing better onboarding and training, creating a better taxonomy, focusing on pattern examples not usage or research, increasing new pattern awareness, and making sure that patterns were approved and up to date. They also made sure to get qualitative and quantitative data around new patterns.

As part of this next wave of changes, he also created a Product Design Steering Group (PDSG), to get design leaders together and help craft the vision. The established design principles, and provided approval of new patterns. It also helped with career development / laddering, and which tools were being used. By making a broader grup part of the decision-making process, he also ensured that they became part of enforcing those decisions.

They also shifted how / where decisions were made:

If things happened in Design Review that couldn’t be resolved, there were clear steps for escalation. They also made changes to how reviews were done. Rather that retrospectives, the goal was to see how work was happening in process:

INitially only design and researchers were allowed to attend. Researchers mostly observed. But they opened those meetings up to a larger organization – so it became more fvisible that it wasn’t just reskinning things and thinking about business. Produt Managers were invited as well, so they could learn from each otehrs’ decision-making. Reearchers came and presented research, including work that would inform the design under review.

The McKinsey process was just way too complicated – they threw it away. They simplified into five steps:

They also started using real-time communication through Slack around which pattern to use, where to find a certain pattern, etc. Or to invite people to add new components to the design system.

They also needed to improve the partnership with engineering. Design and development both want consistency and stability. How to make engineering an ally for the design system? They also explored how to connect the design pattern library with the Story Book (code).

How do you get others to care?

• You can’t be the only one cheering. People started thinking of him as the patterns and consistency guy, so he had to approach conversations differently. It is important to change voice and vocabulary based on who you are speaking with. As one speaker mentioned yesterday, you have to connect their values to what you are trying to do. For example, he talked with Product Managers about speed or reduction in costs.
• Someone working on a new pattern would lead efforts, get input from others in the orgnaizaiton, and then share results at a large company forum – this helped to show the impact that collaboration can have.

He left Trip Advisor a month ago, but they are looking for a dedicated DesignOps lead – they realized that it can’t be a side hustle to focus on these problems around how we do design. They are also looking to manage growth better – new patterns are being created daily. How do you deal with that, especially when almost nothing is taken away? Finally, they want to ensure full design to code parity, and ensure that the workflow is designed before it’s built.

Here are his lessons learned:

Starting with something – however imperfect – is better than nothing. The Steering Group should include multiple disciplines, not just design. Create ways for people to engage in real-time. Make sure you really understand how it’s working using structured interviews, regular surveys … and start with a baseline. Make sure that others can broadcast your wins; empower other people and give them the tools to tell your story – and ultimately make it part of their story. And don’t forget that things will not go as planned, but have the mindset that you can always turn it around.