Design Systems Are Adoption Systems

The uncomfortable thing about design systems is that the Figma file can be beautiful and the system can still fail.

I have seen this happen in small ways. A token set gets cleaned up, a component library gets rebuilt, the docs get a round of care, and everyone agrees the work is more coherent than before. Then product work resumes. Someone copies an old pattern because the new one feels slower. A developer hardcodes a value because the token name reads like internal archaeology. A designer detaches a component because the variant matrix makes a common case feel like a special request. Nobody is trying to sabotage the system. The system has made the correct behaviour too expensive.

That is why I think design systems are adoption systems first.

The component is only one part of the deal. The real system is the path a team takes when they make an interface decision under pressure. Which token name appears in autocomplete. Which prop makes the safe thing obvious. Which doc answers the question at the exact moment someone is about to guess. Which review comment teaches the pattern instead of just rejecting the diff.

If adoption is the lens, the work changes shape. You stop asking, “is this component complete?” and start asking, “what will someone do at 5pm when they need this to ship?” That question is less glamorous, and much more useful.

Tokens Need to Feel Boring

A token architecture that requires a diagram every time someone opens the file is already leaking effort. Good tokens feel boring in use. The interesting thinking sits underneath: primitive values, semantic aliases, component-level affordances. The person building a screen should not need to remember the brand palette or the spacing scale. They should reach for --color-text-subtle, --space-300, or a component prop and move on.

Naming matters more than people admit. Rename a token and you will feel it in every diff for a week. Pick a clever name and someone will misread it later. The best token names rarely sound impressive. They sound like a team agreeing to stop reopening the same tiny argument.

Components Need Escape Hatches With Taste

Strict systems often fail because they confuse consistency with obedience. Teams still need to solve product problems. If a component cannot stretch without being detached, the system has pushed the messy part outside its own walls.

The answer is not infinite flexibility. That just moves the chaos into props. The better answer is opinionated flexibility: a small set of variants, slots, and composition rules that cover the real product surface. If an escape hatch exists, it should be named, documented, and reviewed like any other part of the API.

That is the design engineering job in miniature. You are deciding where freedom belongs.

Documentation Is a Product Surface

Most docs are written as proof that the system exists. Useful docs are written for the moment before someone makes a mistake.

The best documentation is short at the top and precise when it needs to be. It shows the default path, the common exception, and the thing people keep getting wrong. It also admits trade-offs. If a component exists because the design team chose maintenance over expressive range, say that. Teams adopt systems faster when the reasoning is visible, because they can predict the next decision instead of memorising rules.

Governance Should Reduce Theatre

Governance has a bad reputation because it often arrives as ceremony. A weekly meeting. A board. A checklist. More people watching the same decision move slowly.

Good governance is lighter and sharper. It creates a place for decisions to land, then removes ambiguity from future work. A rejected component request should leave behind a reason. An approved pattern should leave behind a reusable path. If governance only produces opinions, it becomes taste policing. If it produces reusable decisions, it becomes infrastructure.

The Real Metric Is Friction

I do not trust design system success stories that only talk about coverage. Coverage says the parts exist. It does not say whether teams can use them without side quests.

The better signal is friction. How often does a team pause to ask which pattern applies? How often does implementation drift from design because the handoff uses a value the codebase cannot express? How many review comments are about fundamentals that the system should have handled already?

Those questions are hard to put in a neat dashboard, which is probably why they matter. A design system wins when the right decision becomes the easiest decision on an ordinary Tuesday.