A design system is a product. Treat it like one.

Most design systems I’ve seen were built by good people and still ended up half-used. The components existed. The documentation existed. Teams kept building their own buttons anyway.

The reason is almost never craft. It’s that the system was run as a library — a place components go — rather than as a product with users, a roadmap and a reason to keep existing.

zeroheight’s 2026 Design Systems Report puts numbers on how common this is. Only 8% of teams describe their system as very stable. 34% say unstable and another 10% very unstable, which is where the report’s headline 44% comes from. Buy-in satisfaction fell from 42% to 32% in a year, and dissatisfaction nearly doubled, from 23% to 40%.

Two things to know before you lean on those numbers. The sample is 147 practitioners, which is small, and it skews to large organisations in North America and Western Europe. And the report is published by a company that sells design system documentation tooling, with product calls to action between the sections. I still think it is the best annual read in this field, and the findings below match what I’ve seen, but a vendor survey isn’t a census and shouldn’t be quoted as one.

That’s not a tooling problem. Tooling has never been better.

Your users are internal, and they can walk away

The first thing that changes when you treat it as a product is who you think you’re serving.

Your design system has users. They’re the designers and engineers around you, and unlike your real customers they have a permanent, free alternative: build it themselves. Every component you ship competes with forty minutes of someone’s afternoon — and often loses.

There’s a finding in the report that settles an argument I’ve had more than once. Trust in design systems is healthy: 42% report high trust and 49% moderate, with only 8% low. Adoption isn’t: 7% fully adopted, 31% widely, 38% moderately and 22% minimally.

People trust the system and still don’t use it. Whatever is blocking adoption, it isn’t that they think your components are bad. That rules out the fix most teams reach for first, which is raising quality.

That reframes adoption entirely. If a team bypasses your date picker, that’s not non-compliance. It is churn, and churn has a cause. Maybe your version doesn’t handle their locale. Maybe it isn’t in the framework they use. Maybe they couldn’t find it. Each of those is a product defect with a different fix, and you can’t tell which one you’ve without asking.

So when a component gets bypassed, I ask three things. What did they need that we didn’t have? How long did their version take? And would they switch back if we shipped the missing piece? The third one tells you whether to build it.

Measure what happened, not what exists

Here’s the finding I keep coming back to, because it names a failure I’ve made myself. Look at what teams actually track. Adoption and component usage in design tools sit at 41% each, component usage in code at 38%. Product consistency is 26%. NPS is 9%. Return on investment is 5%.

So what do we count? The things that are easy to count. Coverage is also easy to move: you can raise it by shipping components nobody asked for. It tells you what exists, not what changed. One team in twenty is measuring whether any of it paid for itself, and then we wonder why the budget conversation is hard.

Outcome measures are harder and they pay. Figma’s 2026 write-up on the business case has two examples I’d borrow, with the same caveat as above since Figma also sells into this market. Grammarly ran an internal survey and found their design system saved design and development teams 25% of their work week. Freshworks credited its new system with a 28% reduction in customer service costs and better time-to-resolution on support tickets.

Note what both of those are. Grammarly’s is a survey — self-reported, imperfect, and still more useful than a component count. Freshworks tied the system to a metric leadership already watched rather than inventing a design metric and asking leadership to care about it.

That is the move. Find the number your executives already read every month, and show your system moving it. I wrote about this failure mode in a different context in coverage isn’t value, and design systems are where I first learned it.

Versioning is the product decision nobody wants to make

A library changes things. A product changes things on a schedule, with notice, and takes responsibility for what breaks.

Decide this early and people trust your system. Leave it and they route around it. You need answers to four things: what happens when a component’s API changes, how long the old version keeps working, who does the migration, and whether a breaking change can ship in a minor release. Write them down before you need them, because the first time you need them is an argument.

The uncomfortable part is that this constrains you. Once you promise stability, you can’t refactor freely, and some decisions become expensive to reverse. That’s what it means to have users.

Tokens are the interface, and most teams stop halfway

Design tokens are where a system either scales or quietly forks. The report shows the field is partway through this: only 10% of teams operate with a single token layer, so a primitive-plus-semantic split is now standard, but a full three-tier architecture is only in place at just over half of the teams surveyed. Only 21% have cross-library aliasing set up, despite multi-brand systems dominating the conversation for a year.

That gap between discourse and practice deserves a second look before you copy whatever the most-cited team is doing. The bleeding edge being loud does not mean the model is ready.

My practical position: go to semantic tokens early, because that’s the layer that lets you rebrand without touching components. Go to a third tier only when you have a second brand or a second platform actually in flight. Building for a multi-brand future you don’t have yet is how systems acquire complexity nobody is resourced to maintain.

The part that’s a marketing job

The report’s sharpest finding is about people rather than code. Among teams with good adoption, 59% credit communication and community. Among teams without it, 36% blame the lack of the same thing.

Now look at who is staffed for it. 44% of teams don’t focus on community building at all. Another 41% spread it across several people. 14% have it as part of someone’s job. One team in the whole survey had someone on it full time. Communication and community building also carried the highest dissatisfaction rate anywhere in the survey, at 40%.

So the thing practitioners say drives adoption is the thing almost nobody is resourced to do.

If you run a design system, a meaningful share of your week is internal marketing. Release notes people actually read. Office hours. Turning up in the channel where a team is about to build their own thing. It’ll feel like it isn’t the work. It’s a large part of the work, and the systems that survive are the ones where somebody accepted that.

What I’d set up on day one

An owner with decision rights, not a committee. A published versioning and deprecation policy. One outcome metric your leadership already tracks. A contribution path so teams can add rather than fork. And a standing slot in someone’s calendar for talking to users, because a system nobody is listening to is a system people will eventually route around.

None of that is design work. All of it is product work. That is the point.

Common questions

What does it mean to run a design system as a product?

It means the system has a named owner with decision rights, a roadmap, a published versioning and deprecation policy, a contribution path, and adoption measured against outcomes rather than component counts. The internal designers and engineers who use it are treated as users who can choose not to, because they always can.

How should you measure design system adoption?

Coverage and component usage are the most common measures, but they show what exists rather than what changed. In the 2026 survey, adoption and component usage were each tracked by around 40% of teams while only 5% measured return on investment. Outcome measures are stronger: tie the system to a metric leadership already tracks. Grammarly's internal survey found 25% of the design and development work week saved, and Freshworks credited its system with a 28% reduction in customer service costs. Both are vendor-published and self-reported.

Why do design systems fail?

Rarely for craft reasons, and rarely because people distrust them. In zeroheight's 2026 survey of 147 practitioners, 42% reported high trust in their system and 49% moderate, while only 7% said it was fully adopted. Systems fail when nobody owns them, when breaking changes arrive without notice, when components do not cover real cases, or when nobody is resourced to communicate. 44% of respondents described their system as unstable or very unstable.

How many token layers should a design system have?

A primitive-plus-semantic split is now standard, with only 10% of teams operating on a single layer. A full three-tier architecture is in place at just over half of teams. Move to semantic tokens early, since that layer lets you rebrand without touching components. Add a third tier when a second brand or platform is actually in flight rather than in anticipation of one.

Who should own the design system?

One person with decision rights, supported by a contribution process. Committees are slow at exactly the moments a system needs to be decisive, and shared ownership tends to mean nobody is accountable for adoption.

What is the business case for a design system?

Tie it to a metric leadership already tracks rather than inventing a design metric. Only 5% of teams in zeroheight's 2026 survey measured return on investment at all, and that's why the budget conversation is hard. Published examples include Grammarly's internal survey finding 25% of the design and development work week saved, and Freshworks crediting its system with a 28% reduction in customer service costs. Both are vendor-published and self-reported.

Why do teams build their own components instead of using the design system?

Because they can, and it's often faster than waiting. Treat it as churn rather than non-compliance and find the cause: a missing case, the wrong framework, or a discoverability problem. Each has a different fix. Ask what they needed that you did not have, how long their version took, and whether they would switch back if you shipped the missing piece.

Does low adoption mean people distrust the design system?

Usually not. In zeroheight's 2026 survey 42% of respondents reported high trust and 49% moderate, while only 7% said their system was fully adopted. People trust these systems and still do not use them, which rules out raising component quality as the first fix.