“Use tokens” is the advice everyone gives and almost nobody makes concrete. A token is not a variable with a fancy name. It is a layer of indirection: a decision you make once, in one place, that every component downstream agrees to inherit. The value of that layer is invisible right up until the moment you change something and watch it land everywhere at once.
So instead of describing it, here is the thing itself. The playground below is the same three-tier token system this site runs on. Move a primitive and watch it propagate through the components in real time.
Move one decision, watch it propagate
A design token, made visible.
One source of truth, many components in sync. Move a slider and the card on the right reacts. That’s a design system in miniature.
No JavaScript per component. Just CSS variables.
Button & Card components updated
Radius and spacing tokens now drive both. Change one number, two components agree.
Try setting radius to 0 for a brutalist feel, or 28+ for friendly & rounded.
Nothing in those components was updated by hand. Each one reads a semantic token, the semantic token references a primitive, and the primitive is the only value you actually changed. One edit, one source of truth, every consumer in sync.
Intent in the middle, value at the edge
The reason this works is the middle tier. A primitive is a raw fact (coral-500 is a specific orange). A component should never reach for that fact directly. It asks for an intent instead: “accent,” “surface,” “danger.” The semantic token sits in between and decides which primitive that intent currently resolves to.
That indirection is what makes theming and dark mode cheap rather than catastrophic. You do not rewrite every component to support a second theme; you repoint the semantic layer at a different set of primitives, and the components come along for free, because they were only ever asking for intent.
It is also why naming matters more than people expect. A token called blue-600 describes a value and locks you to it. A token called accent describes a decision and lets the value move underneath it. Names that describe intent are load-bearing. Names that describe value are decoration.
Is yours load-bearing or decorative?
Token architecture is one of the five things I look at when I audit a design system. If you want a quick read on where yours stands, the design-system scorecard has a handful of questions on exactly this. Ten minutes, and you will know whether your tokens are doing real work or just sitting there looking organized.