Every failed design system I’ve seen had good components.
The tokens were defined. The documentation was thorough. Someone had clearly spent a lot of time building the Figma library, and even more time writing the guidelines for when to use which variant. The system, on its own terms, was solid.
Six months after launch, teams weren’t using it. Or they were using it selectively, working around the parts they didn’t trust. Or different product areas had started building their own components that diverged from the system in ways that were now too embedded to unpick.
The components weren’t the problem. They never are.
Design systems fail for organisational reasons. This sounds obvious, but most design system work still gets framed and funded and resourced as though it’s a craft problem.
Build better components. Write better documentation. Make the Figma library easier to navigate. These things matter at the margin. They don’t determine whether the system survives.
What determines survival is whether the teams who are supposed to use the system had any say in how it was built, whether there’s a clear ownership model for maintaining it, whether it has the organisational backing to be treated as infrastructure rather than a nice-to-have, and whether the team building it understands that adoption is a change management problem rather than a design quality problem.
Most design systems are built by a small, specialised team with a strong point of view, then handed to the rest of the organisation with the implicit expectation that people will use it because it’s better than what they were doing before.
Sometimes that works. Often it doesn’t, because people don’t change behaviour based on quality alone. They change behaviour when the change is easy, when there’s a reason to trust the system, and when the cost of not using it becomes visible.
The trust question is particularly important and particularly underestimated. A component library built without input from the product teams using it is asking those teams to trust something they had no hand in shaping. That’s a significant ask, especially in organisations where design and engineering have historically had friction, or where different product areas have meaningfully different needs that a one-size-fits-all system doesn’t account for.
I’ve seen design systems teams do extraordinary component work and then be genuinely confused about why adoption is low. From the inside, the resistance looks irrational. From the outside, it looks like exactly what you’d expect when you build something for people rather than with them.
The systems that stick are the ones that treat adoption as the primary success metric from day one. That means getting product teams involved in the process early, even when it’s slower and messier. It means being honest about the parts of the system that are prescriptive and the parts that are flexible. It means having someone whose actual job is to support teams in using the system well, not just to build it.
It also means being honest about what the system is for. A design system is not just a tool for design efficiency. It’s an organisational agreement about how a product should look and behave. Like any agreement, it needs buy-in from everyone who’s expected to honour it.
The maintenance question is where most systems quietly collapse. You can launch a design system. Getting an organisation to fund its ongoing maintenance is a different and harder problem, because maintenance is invisible. Nobody celebrates the fact that the button component still works correctly eighteen months after launch. But when it doesn’t, everyone notices.
The teams that handle this best treat the design system like a product rather than a project. It has a roadmap. It has stakeholders. It has a backlog. Someone is accountable for its health. When that’s not true, the system slowly calcifies. It stops evolving with the product. Teams start working around it. Eventually it becomes legacy infrastructure that everyone agrees in theory should be updated and nobody has the mandate or resource to touch.
Good components are necessary. They’re not sufficient.
Build the system for the organisation you’re actually working in. Not the ideal version of it. That’s where the work lives.
