The design system nobody uses

After years working on design systems, I learned that adoption doesn’t fail at launch. It fails six months later, quietly, when people find faster ways to work around what you built.

And yet it keeps happening. Teams spend months building solid foundations — semantic tokens, accessible components, polished documentation — only to watch designers still using hardcoded colors in Figma and developers copying styles from some old file. The system exists, but nothing changes.

The problem is almost never technical.

The numbers back this up. According to the zeroheight’s Design Systems Report 2026, only 7% of teams report full adoption across all teams. For the fifth consecutive year, driving adoption tops the list of the biggest challenges in the field. Five years in a row. It’s not a new problem waiting for a new solution. It’s a structural one that the industry keeps not solving.

Adoption is a trust problem

Here’s the counterintuitive part: 91% of teams report moderate to high trust in their design system. People trust the system. They just don’t use it consistently. The report itself puts it bluntly: trust isn’t the bottleneck. Something else is.

When a designer skips the design system, the real reason is rarely “I don’t know how it works.” It’s usually: I don’t trust it to be flexible enough for what I need or last time I used it, I lost more time than I saved.

These are perceptions, not facts. But perceptions drive behavior.

A design system earns adoption when the people who should use it feel it’s on their side. That it helps them work better, rather than forcing them into compromises.

The gap between builders and users

The team building the system and the people using it daily rarely share the same perspective. The system team thinks in terms of consistency, scalability, and maintainability. The product designer thinks about delivering the screen by Thursday.

These priorities don’t have to conflict, but they often feel like they do.

Governance isn’t control

One mistake I’ve seen repeatedly: treating governance as a permissions problem. Who can add components, who can modify tokens, who approves PRs. All valid, but nowhere near enough.

Real governance is an ongoing conversation. Who flags when a component doesn’t cover a real use case? How are those requests tracked? How quickly are they resolved?

The 2026 report reveals a telling gap here: 44% of teams don’t focus on community building at all, and across all 147 teams surveyed, only one had a dedicated full-time person for it. Yet communication and community rank among the top drivers of adoption. Teams know it matters. They just don’t invest in it.

When the feedback channel is slow or opaque, people stop using it. They start solving problems on their own, outside the system. Which is exactly what you don’t want.

A healthy design system has clear contribution paths, predictable response times, and — most importantly — shows that feedback actually leads somewhere. Even when the answer is “we can’t do this right now, and here’s why.”

Adoption as a metric, not a hope

Measure adoption. Go beyond the number of published components or documentation coverage. Look at how many product screens actually use system components. How many tokens get overridden. How often the system gets updated versus worked around.

Only 41% of teams currently measure adoption in any meaningful way. That’s the same industry that wonders why leadership buy-in is dropping — down from 42% to 32% satisfied in just one year. You can’t make the case for resources if you can’t show the data.

These numbers are uncomfortable at first. But they’re the only ones that tell you where you really stand.

The best-adopted design system isn’t the most complete one. It’s the one that figured out how to be genuinely useful to the people it’s supposed to serve, in the work they do every day.

—
Data from the Design Systems Report 2026 by zeroheight.