A design system is not just a box of tokens and components.
Tokens help. Components help. Documentation helps. But the real value of a design system is that it makes common decisions easier to make well.
A good system is a decision system.
A spacing scale can tell you that 16px, 24px,
and 32px are available. It cannot tell you which relationship
you are designing.
Is this gap inside a component? Between related controls? Between sections? Between the page heading and the main content?
Those are different decisions. If the system only gives values, people still have to guess how to use them.
The useful part is not "we have spacing tokens." The useful part is "tight gaps group related things, larger gaps separate ideas."
A button component should not only store colors and padding. It should carry rules.
Those rules are the system. The code is just where the rules become hard to forget.
Reuse is good when the problem is the same. It is bad when it hides a different problem under a familiar component.
For example, a small empty state inside a filtered table should not necessarily reuse the same layout as a first-run empty dashboard. They are both "empty states," but they have different jobs.
One should teach and guide setup. The other should explain why the current results disappeared and how to reset the filter.
A good design system helps people decide when reuse fits and when the pattern needs a variant.
Variant sprawl is what happens when every small need becomes a new option. Soon the component has twelve sizes, seven tones, four layouts, and no one knows which one to use.
But refusing variants can be just as bad. If a compact table toolbar and a marketing hero button use the same button rules, one of them will feel wrong.
The question is not "can we make a variant?" The question is "does this represent a real product difference?"
Density, danger, prominence, and context are real differences. One-off taste changes usually are not.
A system that allows everything is not a system. It is a folder.
Sometimes the best design system contribution is saying no to a local solution. Not because consistency is sacred, but because the local solution creates future confusion.
If one screen invents a new warning badge, the next screen has to decide whether to use the old badge or the new one. If one modal uses a special footer layout for no clear reason, every future modal review gets harder.
Consistency saves attention. It lets teams spend energy on the parts that are actually unique.
Component docs often show props but not judgment.
"Use variant='secondary'" is less useful than "Use secondary
actions when the action supports the primary task but should not compete
with it."
The second version teaches a decision. That helps designers and engineers make the same call in new situations.
Do not judge a design system only by how many components it has. Judge it by how many repeated decisions it removes.
Tokens create consistency at the value level. Decision systems create consistency at the product level.
That is where design systems become useful: not when they store every style, but when they make the next good decision easier.