Why Do Some Companies Build a Design System That Nobody Uses?
Many companies spend months building a design system. Components are prepared. Documentation is written. Tokens are defined. There are even launch meetings.
A few months go by and the same sentence starts coming up: “The team isn’t using it anyway.”
So why?
Working on design system projects at different scales, I’ve noticed one common truth:
The systems that failed didn’t lack components. They lacked adoption.
Because many companies focus on the easiest part of a design system: building it.
The hard part is getting people to use it every day.
The problem isn’t the design system, it’s habits
A design system doesn’t need to look perfect to succeed.
It needs to be used.
If designers keep using old components, developers prefer to write new ones or PMs make product decisions without considering the standards, even a technically flawless system will fail.
Because a design system isn’t a technical project; it’s an organisational transformation.
People choose what’s easy, not what’s right
If a designer can’t find the component they need in 30 seconds, they’ll create a new one.
If a developer has to read long documentation to understand an existing component, they’ll write their own solution.
At that point the problem isn’t the team.
The problem is that the system doesn’t make everyday work easier.
A good design system doesn’t force teams to follow rules; it makes the right way the easiest option.
A system without an owner doesn’t live long
In many companies, once a design system is built it’s treated as a finished project.
But as the product evolves, the system has to evolve too.
New needs are evaluated.
Unused components are removed.
Standards are updated.
And for that, the system needs an owner.
That person or team is responsible not only for adding new components, but also for protecting the integrity of the system and managing feedback from the teams.
So how does a design system get adopted?
Adoption doesn’t start with adding new components; it starts with making the teams’ daily work easier.
Here are a few approaches I’ve seen work.
1. The design system should be the fastest option
Teams use it not because it’s right, but because it’s fast.
If rebuilding a component is easier than searching for it, the problem is the system, not the user.
A design system shouldn’t slow work down; it should speed it up.
2. Build the system together
A design system shouldn’t be something only the design team owns.
When developers, PMs and other stakeholders are involved, the system becomes a shared language.
People are more likely to adopt systems they helped create.
3. Measure success by usage
How many components you’ve built doesn’t matter.
What matters is how many of the newly built screens use the existing design system.
If teams keep coming up with new solutions, the problem most likely isn’t the design system itself but the adoption process.
4. Manage the design system like a product
Successful companies don’t see their design system as a project to be finished.
It has a roadmap, a backlog, releases and user feedback too.
Because a design system is a living product.
Conclusion
Building a design system is technical work.
Getting it adopted takes leadership, communication and organisational management.
That’s why successful companies don’t start by answering “What kind of design system should we build?”, but
“How do we build a system that teams will want to use every day?”
Because unless people use it, even the best design system in the world will remain nothing more than a tidy-looking Figma file.
