Design systems fail for many reasons. Total disaster is rare. It’s more common that a project takes too long, or doesn’t serve the teams it’s meant to help.

Here are 11 reasons we’ve encountered:

Scaling problems
Bias for the boardroom
Lack of consensus
Unclear ownership
Gaps in the technology stack
Inflexibility
Multi-brand complexity
Short reach
Pre-digital legacy
No organising principle
Unrealistic ambition

Let’s take them one at a time, along with how we mitigate them.

1. Scaling problems

Small organisations have different ways of working to larger ones. If they don’t adapt as you grow, problems can arise.

If three teams use your design system, it’s easy to get feedback about a change. You can go and talk to them. If you have 30 teams, you need processes to make that work.

As you grow, watch for communication breakdowns and address them quickly.

2. Bias for the boardroom

External agencies sometimes build design systems for organisations, not with them.

The person making that buying decision usually isn’t responsible for the project’s success. The work might impress leadership, but not work for the teams saddled with it.

Instead, embed the agency into your organisation for as long as needed to understand teams’ needs and deliver the design system.

3. Lack of consensus

Design system means different things to different people. It could encompass the brand, design elements and technology components. Or it might only cover typefaces and colours.

There’s no right definition, but different perceptions create risk. Agree on what problems to solve, and set the scope and goals to solve them.¹

4. Unclear ownership

A design system could originate in your design, engineering or brand teams. When it germinates in one team, it’s likely it only fulfils that team’s needs. That’s a good place to start, so long as it expands to serve the whole organisation.

The original team shouldn’t own the design system, but it shouldn’t be reduced to a service team either. Too much authority, and the system will stay a one-discipline tool. Too little, and their ability to innovate is compromised.

Allow all teams the maximum freedom feasible. They’ll be more empowered to innovate — and happier with it.

Support collaborative communication and tooling such as:

Version control
Pull requests
Documentation
Automated testing
Access control

5. Gaps in the technology stack

It’s hard to make the design system work with all the technology used in the organisation. You may not have aligned around a technology stack, or decided not to. Maybe shadow IT is hiding in team workflows.

The design system doesn’t have to integrate with everything, but if it’s disconnected from essential parts, it won’t flourish.

Identify and agree necessary touchpoints to make sure all teams’ needs are met.

6. Inflexibility

Design systems fail when they don’t allow for change. Rebrands², acquisitions and new needs arise. You can’t plan for every change, but an adaptable system prevents headaches.

If your organisation needs a design system, it’s likely to have different project teams working at different speeds. It’s not realistic for everyone to adopt the latest version of the design system on release.

If you don’t use a monorepo, use robust versioning. This helps teams make the best decisions for their project. We recommend Semantic Versioning to flag the implications of an update for different teams. It flags mission-critical updates that affect existing implementations.

7. Multi-brand complexity

Managing several brands with one design system is complicated. You could be dealing with variations in theming or distinct identities. The design system must support each sub-brand’s uniqueness, and its cohesion with its siblings to the extent needed.

Identify where your needs fall on this spectrum. It gives you a reference point for decisions about what the design system should do — and how.

8. Short reach

Design systems aren’t only for the web. To make your UI consistent, identify everywhere users interact with your brand. Then decide what your design system should include.

Consider:

Web (desktop and mobile)
Native apps (desktop and mobile)
Emails
Social media
Support documentation
Digital advertising
Print, physical media and merchandise

You don’t have to include everything at once. Web and mobile are a good place to start.

9. Pre-digital legacy

Your starting point could be a brand guide developed for print, or other non-digital contexts. You might inherit an inaccessible colour scheme, a typeface that doesn’t support internationalisation, or a logo that doesn’t work in digital contexts.

Some organisations overlook digital in their foundational strategy. This makes life hard for digital teams charged with implementing it. There’s also a risk of leaders underestimating the scale of moving to digital.

But it’s also an opportunity to modernise. Make sure your design, technology and other brand-aware teams are in the room from the start.

10. No organising principle

To build a Lego castle, buy a set, not a tub of random bricks. Without an organising principle, your design system could become a collection of things that aren’t used, or used in disparate ways.

The principle could be anything that helps you filter out ideas that won’t help you build what you need. For example:

Composability: will it work consistently in different contexts?
Platform-specificity: e.g. should you build only with React?
Scalability: will it still work in a multi-brand future?

Identify a logical organising principle for the aims of your project.

11. Unrealistic ambition

Design systems fail when you try to do too much too soon.

Don’t try to eat the whole horse. Start with foundational elements like fonts, icons, design tokens, or logos. Then pivot to the processes that get people to use them, talk about them, and share feedback.

It’s tempting to fork old design-system work, but that’s like taking your carpets with you when you move house. It won't achieve the best results.

Remember: anyone that has built a good design system had to build a bad one first.

See Don’t build a design system — build what you actually need. ↩
See Scott’s Law of Rebrands, on the inevitability of rebrands happening, and how to plan for it. ↩

Why design systems fail