Why design systems fail

I got 99 problems but components ain’t one…

I worked on my first design system back in 2006 (as a point of reference, the original iPhone launched in 2007, and the first iPad in 2010). At the time, I worked for a large enterprise software company with just a handful of UX team members and a huge product catalog, built exclusively through acquisitions (which means different branding, different tech stacks, and different cultures). It took almost 10 years and multiple design system attempts (and failures) before we finally started gaining traction with design system work. I discussed my experiences in my 2016 talk Taming the Enterprise, where I shared the root cause for our early failures, as well as our eventual success: our ability (or inability) and willingness to communicate and collaborate across teams and disciplines. None of our core issues were caused (or solved) by tools or technology.

I’m back to design system work again, this time as a consultant. Despite the speed of evolution in the digital space, including the influx of new tools and libraries, it feels like not that much has really changed.

I took to LinkedIn and Twitter recently to ask the following question:

“When a design system project fails to deliver on expectations (whatever those may be), what have been the observable failures or issues, and what do you think are the underlying causes of those issues?”

The responses I received aligned almost perfectly with what I saw back in 2006, back in 2016 when I wrote “Taming the Enterprise”, and now, in 2023, when I’m back into the design system space.

So, what are these patterns of failure?

1. No shared (and contextual) sense of purpose
2. Overbuilding, or scaling too early
3. Inability to make decisions and move forward quickly
4. Lack of clear ownership and dedicated resources
5. Lack of cultural alignment

Let’s explore each of these in more detail.

1. No shared (and contextual) sense of purpose

Amy Hupe gave a great talk at the 2022 Clarity Conference titled “Down with Design System Dogma”. She emphasized the importance for a team to align on the purpose of a design system before creating outputs, and she pushed us to think beyond the most commonly accepted promises of a design system: consistency, efficiency, and scale.

Consider what is unique about your organization, your teams, your products, your challenges and opportunities. Answers to the following questions can help you surface that unique contextual purpose:

1. What prompted the decision to invest in a design system?
2. How do you anticipate the design system changing the way your teams work together and deliver products to your customers?
3. What are your product OKRs/KPIs, and how will a design system help your teams achieve those goals?
4. How should the design system affect the user experience of your product?
5. How will you measure impact and make continual improvements?
6. And, after you have the answers to these questions, it’s important to consider this final question:

Are your expectations of the design system realistic?

For example, a common “purpose” I hear from teams is “improve the UX of our products.” I’m sorry, but that’s essentially meaningless. However, if you can describe what an improved experienced might mean to your customers, how it will change their behavior, and the impact those changes will have on your organizational bottom line, then you get closer to your purpose.

I like to think about design systems not as a set of components, but a collection of decisions that have been formalized (and ideally validated). Clarifying purpose helps you prioritize which decisions to formalize. Then, by formalizing those decisions, you eliminate the small decisions a team has to make and the recurring problems they need to solve for, which provides more space and creative energy for the big decisions and unique problems. That’s how you improve the UX of your products.

2. Overbuilding or scaling too early

A common recommendation among design system enthusiasts is to treat your design system like a product. By this, they usually are referring to a dedicated team (more on that below), continual evolution based on feedback, etc. And that is correct.

But those things are for existing products. We rarely talk about how to validate the approach and investment prior to committing to a full scale design system. The cardinal sin of product is to build without validating first. What might an MVP of a design system look like? How will you validate with your users —the product teams using it to build and deliver?

The most successful design systems often start with grass roots efforts at an individual team level. But in a desire to leverage that success more broadly, organizations often jump to immediately scaling vertically—make the design system bigger and therefore more complex to both use and manage—before considering what is actually relevant to other teams and scaling that horizontally. Identify your lowest common denominator: the smallest set of shared decisions and resources that can provide value across all teams. By using a small, experimental approach, transplanting approaches from one team into another, and then observing results before scaling further, you can better identify what ideas hold the most potential for being systemized across all teams.

There is a misconception that a design system can only provide value if it is comprehensive, covering the majority of use cases your teams may encounter. Consider the Pareto principle, aka the 80/20 rule. A design system that supports the right 20% of the user experience can drive 80% of the business outcomes, if you have carefully considered the questions about purpose outlined above. A small, iterative approach also allows you to design components (and other resources) in-context, introduce changes to users slowly, and incorporate both internal and external user feedback when it can still be impactful. Even more importantly, starting small and iterating in small increments helps you validate your investment at each step of the way, exactly how good product work is done.

3. Inability to make decisions and move forward quickly

Call it lack of urgency, analysis paralysis, or even navel-gazing (a term that came up many times in my discussions), a lack of an explicit decision making structure and cadence often makes design system projects stretch out much longer than they should.

Yes, there are important decisions to make when building a design system—but not all decisions are of either equal importance or urgency.

For example, I’ve seen, many times, design teams agonize over selecting the “right” color scheme and fonts for a design system. I’m going to tell you something: once you account for accessibility, readability, and appropriate levels of contrast for visual hierarchy…it doesn’t matter. Some of your users will love what you choose, and some will hate it, regardless of how attached you are to it.

This affects more than just time to deliver. Decision fatigue is real. When you treat all decisions of equal importance, you don’t have the appropriate energy to devote to the truly important, impactful ones.

A few things I recommend to teams:

1. Decide what is important to your industry, product, and team. Impact looks different for consumer vs. enterprise apps, for example. Design for your context, not anyone else’s. What 20% of effort will drive that 80% of value for you and your customers?
2. Plan the project so decisions are stacked: each big decision lays the foundation for the next decision to come.
3. Be patient with moving slowly at first; trust that momentum will build as you layer these decisions. Starting slowly but thoughtfully will end up getting you good results faster in the long run.
4. Set a process and timelines for decision making. Time box discussion, then make the call.
5. Build in small increments so no one decision carries too much weight.

4. Lack of clear ownership and dedicated resources

Going back to “your design system is a product”—I bet you don’t expect to deliver quality products with scattered, part time resources. And yet, that is exactly how many orgs treat their design systems. Rather than having a few dedicated team members with clear ownership (which helps greatly with decision making), a large group of people randomly contribute small amounts of time in bits and pieces.

Note, if you start small, you don’t necessarily need full time resources, you just need consistent resources who are aligned on purpose of the work and empowered to make decisions for the organization.

Bottom line, not only does product delivery require resources, it requires investment and engagement, and that comes from dedicated team members who are accountable for the metrics of success. When everyone is responsible for the work, it often ends up that no one is actually accountable for results.

5. Lack of cultural adoption alignment

One of the most common success metrics of design systems is the concept of adoption: the level at which product teams have fully (or partially, or sometimes not at all) adopted the design system into their products.

This focus on adoption frames the problem from the wrong direction. In Taming the Enterprise, I said that “every organization is a special snowflake of dysfunction.” By that, I meant that there is no perfect environment or culture; best practices are only best when they align with how your teams already work (or at least how they want to work).

Rather than cultural adoption, I’d encourage teams to focus on cultural alignment. Whatever you build, it should align with the organic culture (both the healthy and not-so-healthy parts) of the organization and the design, development, and product teams that are the eventual users of the system. Consider what challenges you are currently facing, what needs to change about how your teams are working, and how your design system effort can support that change (all questions you should already have answers to if you defined your purpose). Lean into what is already working well across your teams and start by systemizing that good work (and formalizing the informal ownership and contribution models). Even if it doesn’t align with that book you read, that tweet you saw, that talk you loved. Yes, even this article!

Conclusion

The common thread among these issues is that none are related to technical or tooling decisions —or even to the components themselves.

This work is not easy: organizations have to balance the risk of under-investing in design systems (and getting left behind) with the risk of over-investing before they’ve identified a contextual purpose and strategy. Luckily, there is a great way to surface those risks, and identify the best ways to mitigate them. Using service design early in the process can provide a clarity of context and a vision of how the humans who build and adopt the design systems (and who use the products of those systems) can successfully interact with that system.

By applying the same level of intention and best practices to design systems as we do on our external products, we are much more likely to build design systems that actually meet the needs of our organization, its culture, and its internal and external users.