The Paradox of Design Systems

Design systems have been essential to building better, faster, and more cohesive products at scale. But systems are also restrictive, and any designer will naturally want to push the status quo.

Because we’re problem-solvers and tinkerers by trade, it’s often perceived as faster to work locally rather than align and integrate with a core system first. If the cost to contribute into the system is seen to be too high, it might not be worth the investment by a team. This conflicts with the primary goal of a design system, which is to establish a single, unified visual language, one that everyone adopts, and doesn’t alter constantly. As a result, design systems tend to fall apart, or designers are left feeling creatively stifled. Or worse—both.

We think there’s a solution. We want to tap into a designer’s inherent desire to evolve or even completely rethink parts of our system. We want to create a paradigm shift wherein our designers no longer view themselves as users of the system, but instead see their role as core contributor and co-author of a shared system - one that they have ownership of. In this world, they’d be building the system, rather than fighting it.

We can’t accomplish this by being passive or having an open invitation to contribute. We need to be proactive—encouraging others to contribute is just as critical as building and maintaining the system itself.

Will this actually work? Let’s be real: we’re not sure. But we’ve been testing out our theories as we build new components. Here’s how we collaboratively evolved our Data Table, one of the more complex components within our web tooling system.

We meet designers where they work

As designers working on the system, we function as a conduit of connections between teams—we’re invested in the explorations designers are undertaking, and helping to guide their patterns to a consistent space with other teams. Several teams began to share their work around Data Tables using Wake or in critiques. By having visibility into these sharing mechanisms, we were able to uncover just how frequently Data Tables were used and took note of their functional limitations.

We held roundtable sessions across teams for anyone working with Data Tables to come together. In doing so, we found designers are far more motivated to contribute if they see the direct value that the component or pattern improvement will have on their own product, and how it could be scaled to benefit others.

Everyone brought their relevant screens, framed what they were solving for, and what their expectations would be from the Data Table to the roundtable sessions. This helped everyone understand each other’s needs and challenges. We were able to identify overlaps in solutions and began to define what interactions and styles are shared or core to the Data Table’s functionality.

We involve designers in the process of contribution

Because designers are spread across various parts of the organization, the system team took on the responsibility of taking the core solutions created around the Data Table, digesting it, and presenting their findings to all the stakeholders. This was the perfect time to see how the updated solutions work in context. We found that while teams were starting to align visually, patterns associated with the Data Table (filtering, for example) became a new space for conversation. This helped keep the momentum going.

Once the Data Table was ready to be built, those teams who directly contributed became real-world incubators for their specific use cases to test the component’s attributes and interactions. The benefits of this were twofold:

1. This provides us with constant, relevant feedback relevant to the Data Table’s functionality.

2. It empowers teams to graduate their solutions upwards into the system so that more teams can get the value from the start

Documentation is a communication tool

Throughout this entire process, we partnered with our UX writers to craft the best practices, definitions, and core interactions regarding the Data Table. And because our UX writers are both centralized and embedded within teams, they have a similar sense for how components are being used holistically. Documentation benefits everyone—from a designer just starting to learn more about what we offer, to a developer looking to understand how we differentiate between a Tooltip and a Popover. As a bonus, the process of documenting can help a designer further clarify his or her thinking with regards to the component itself and how it should be used.

We’re investing in how we capture and celebrate contributions in our guidelines and  documentation. This helps us foster a shared ownership mentality and empowers others to be the experts in areas they’re passionate about.

Our designers become system ambassadors

As we scale as a business, it’s important to have evangelists for Design Systems spread across the company. The designers who contributed to the Data Table component were encouraged to share their knowledge back to their respective feature teams. They also became points of contact moving forward, and helped us all stay connected regarding how components, like our Data Table, are being used, where they break down, and how they can continue to evolve. In this sense, both sides become teachers and students of the system, continually learning from each other and improving on the current state.

As we engage other designers with this process, they’re beginning to see how they can influence the entire design language by working together instead of building their own components. This means a bigger impact for them, more utility for other designers and developers, and increase in speed, consistency and quality across the products built at Spotify.

Stay tuned for more from the Spotify Design System team. 👋🏼