A design system is the shared set of building blocks a company makes its products from: the buttons, menus, colours and text styles every team is meant to reuse instead of drawing their own. Many design systems end up barely used. A team spends months building one, launches it, and then sees it fall behind as product teams fork it, which means copying a part and changing it for themselves, whenever the system cannot keep up. I have seen this happen more than once, including on systems I built.
The cause is almost never technical. The named colours and sizes are fine. The buttons and menus are fine. What breaks is the shared understanding that the system is worth the extra effort of following it.
Trust is the actual dependency
Trust drops the first time a team waits two weeks for a component the system does not have. It drops again when they suggest an addition and never hear back. By the third time, they have usually built their own private copy of the system, and they are no longer really using yours.
This is hard to see from inside the system team, because nobody announces it. No product team declares that it is leaving the system. There is a deadline, and a component that nearly fits, and a developer who copies it into their own part of the code and changes two things. That copy is not disloyal. It is the cheapest sensible decision for someone with a date to hit.
Each of those copies is a reasonable decision not to rely on the system. A useful measure of a system's health is how often that decision gets made, and almost nobody measures it.
What happens to a copy over time
A copied component starts out identical to the original, which is why it looks harmless. Then the original gets a visible outline for keyboard users, a fix that makes it usable with a screen reader, a change to how it handles long text on a narrow screen. The copy gets none of that.
Six months later the two are genuinely different components with the same name, and the difference does not show in any screenshot. This is where the cost lands: not in the duplication, which is cheap, but in the drift between the two, which goes unnoticed and grows over time.
By the time anyone notices, the fix is no longer a quick update. It starts with working out how far the two have drifted apart.
Treat it like a product, not an infrastructure project
Infrastructure here means something built once and then maintained in the background. What I have found works better: a real list of what to do next, real choices about what comes first, and someone whose job is to notice the problems product teams run into. Not a team that hands out parts, a team that makes other teams faster.
That shift changes the daily work. An infrastructure team asks what is missing from the library. A product team asks who is currently blocked, and by what, and what would unblock the most people this week. Those two questions lead to very different roadmaps (the plan of what gets built, and in what order), and only the second one tracks whether teams keep using the system.
It also changes who you listen to. Infrastructure teams take requests from whoever is loudest, which in practice often means whoever is most senior. Product teams go and watch. The most useful hour I have spent on any design system was sitting with a developer building a screen with it and saying nothing while they worked.
Your users are not the designers
The people most affected by a poor design system are engineers, and they are usually the last ones consulted about it.
A component, one of those reusable parts, can be perfect in the design file and awkward in code: fifteen settings, three of which cancel each other out, and no way to get the one variation this screen needs without building something around it. The designers are happy, use of the system is falling, and nobody can explain why.
If your system has a design side and a code side, the code side is the product. The design side is the documentation.
Coverage matters more than quality
By coverage I mean how much of what teams need the system actually has. I think a mediocre component that exists is better than an excellent one that does not, though not everyone agrees.
The reason is that partial coverage forces a decision on every screen. Is this thing in the system? Do I check first, or do I just build it? When the answer is "check first" often enough, checking becomes a habit. When the system covers only half of what teams need, checking pays off half the time, and people stop checking.
This is also why the ordinary parts are worth more than they look. Nobody writes a case study about a calendar for picking a date, an inline validation message or what a table shows when it has no rows yet, but those three are the ones teams run into all the time, and they are where copying starts.
Strictness has a cost
Part of the coverage problem comes from how strict the system is about what it accepts. A system that admits fifteen carefully controlled components will be copied more than one that admits sixty rough ones, because the control is a cost paid by the people who most need to move fast.
How strict you are should depend on how much breaks when a part is wrong. A button used on every screen deserves scrutiny. A component two teams need and nobody else will touch does not need a design review board.
Let the tools enforce it
Coverage gets you the pieces. What keeps them in use is that the alternative is inconvenient, and that is a job for the tools rather than for the documentation.
The strongest enforcement is an automatic check, and it works best when it is simple and strict: a colour, a text size or a boldness that is not one of the named ones is refused, and so is any spacing or corner rounding above the smallest steps, with a message that says which kind of named value to use instead. It is not a style preference. It is the difference between "please use the system" in a document nobody reads and a change that does not get past the checks until you do.
The effect is bigger than it sounds. A designer who cannot reach for a grey they happen to like has to use one of the real colours, so whatever they make fits the rest of the product and switches to dark mode without extra work. The constraint does part of the design work. That is the kind of design system that keeps being used: not the one with the best documentation, but the one where doing it properly is the easiest path and doing it differently takes a deliberate exception and a sentence explaining why.
The message matters as much as the rule. A check that says "unexpected value" teaches nobody anything. One that says "use one of the named spacing steps instead of 12 pixels, and if none fits, add one with a note saying why" is documentation delivered at the moment somebody needs it.
Adoption is the metric, and it has to be visible
The components are the output. Adoption, meaning how much teams actually use the system, is the measure of success. The system only works when teams choose it because it makes their work easier, not because someone senior said so.
Making that measurable is worth the effort, and it is easier than it sounds. The share of what is on screen that comes from the system. The number of one-off styles per screen. How long a request waits before it is answered. None of these is perfect, and all of them are better than counting how many components you have shipped, which measures your output and says nothing about anyone else's.
The number that changed the most conversations for me was time to answer a request. Not the time to ship the component: the time to reply with a decision, including "no, and here is why". A quick no keeps a team inside the system. A long silence tends to send them out of it for good.
Mandates raise usage, not trust
Large organisations often end up issuing a mandate from the top: use the system, no exceptions. It works, in the narrow sense that usage goes up.
What it does not do is remove the problems that made people leave. Teams use the system because they have to, and the frustration is still there. That is harder to fix, because people who are frustrated stop telling you about it. They follow the rule, and they also work around it in ways you only find out about later.
A mandate is useful for keeping a habit in place once most teams already have it. It does little to create that habit.
What I would do differently
Start smaller than feels comfortable, and go deep on the parts a team actually builds a screen out of rather than wide on a catalogue of parts.
Set up a way to ask for and contribute components on day one, even if it is a shared channel and a promise to answer within two days. Having that way in matters more than how polished it is, and keeping the promise matters most.
Publish the roadmap together with a no-list, the things you have decided not to build, so a team can tell at a glance whether to wait or to build their own. Uncertainty is what leads to copies. A clear no rarely does.
And measure the result you actually want. Not components published. Not colours named. The number of times someone chose the system when they did not have to, which is the clearest sign that it was worth building.