8.7 Design systems, tokens & component kits

Professional UIs are consistent because they’re assembled from reused, tokenized parts — not hand-tuned screen by screen. Once you think in tokens and components, two things happen: your app stops drifting, and your single most powerful instruction to an AI becomes “reuse what we already have.” This very course is the worked example — its colours, spacing, and type all come from a token file.

Key vocabulary

Design system: The shared vocabulary of a product's UI: tokens (named values), components (reusable parts), and patterns (how to combine them) — applied consistently everywhere.
Design token: A named design value — --accent, --space-4, --radius, --fs-lg — referenced instead of a raw hex or pixel. Change the token and every use updates at once.
Semantic token: A token named for its role, not its value: --text, --border, --accent rather than --green-500. Roles survive a theme change; raw values don't.
Component kit: A library of pre-built components. Tiers: shadcn/ui (you copy the code in and own it), Radix (unstyled, accessible primitives), MUI/Material (a complete styled system).
Theming: Supporting variants like light/dark by overriding only the colour tokens. The components and layout don't change — just the values the tokens resolve to.

Tokens: change one value, change everywhere

A design token is a named value you reference instead of hardcoding. Rather than typing #3fb950 in forty places, you define --accent once and use it everywhere; change the token and the whole app moves together. The win is twofold: consistency (nothing drifts because everything points at the same source) and changeability (a rebrand or a dark mode is a token edit, not a find-and-replace). This site enforces exactly that — every colour is a token, and a build step rejects any raw hex that isn’t one.

FIG 1 · one token, the whole app A single --accent token feeds the Button component, which feeds every screen. Change the token and all of it updates at once.

Reuse: the cure for drift

The reason consistency is hard by hand is that every new screen is a chance to make a slightly different button. A shared component removes that chance: define <Button> once and every instance matches automatically, forever. The anti-pattern is the snowflake — a one-off component built for a single screen that quietly diverges from the rest. When you direct an AI, the highest-leverage rule is “use the existing component, don’t invent a new one” — it’s the single biggest consistency win available.

Tokens as the single source of truth (this site's own)

/* tokens.css — every colour/space/type value lives here, once */
:root {
  --accent: #3fb950;     /* the one brand colour */
  --text:   #e6edf3;
  --border: #30363d;
  --space-4: 16px;       /* an 8-pt spacing step */
  --radius:  8px;
}
/* light theme overrides ONLY the colour tokens */
:root[data-theme="light"] { --text: #1f2328; --border: #d0d7de; }

Components never write a raw #3fb950 — they reference var(--accent). That’s why this site can flip light/dark by swapping a handful of values, and why a build check can fail on any stray hex. “Match our tokens” is a real, enforceable instruction.

Picking a kit

You rarely hand-build components anymore — you start from a kit. The three tiers differ in how much they style for you and how much control (and ownership) you keep.

Kit	What you get	You control	Reach for it when
shadcn/ui	components copied into your repo	everything — it's your code	you want full control + own the code
Radix	unstyled, accessible primitives	all the styling	you have a design and need solid behaviour
MUI / Material	a complete styled system	less — you adapt their look	you want polished UI fast, one cohesive look

All three give you accessible behaviour; they differ in how much look-and-feel is decided for you.

01 Learning objectives

0 / 6 done

02 Curated reading

CSS-Tricks — What Are Design Tokens?
essential 12m — The clearest intro to tokens as the single source of truth.
shadcn/ui — Introduction
optional 10m — The “copy the component in, you own it” model.
Radix UI — Primitives
optional 10m — Unstyled, accessible building blocks behind many kits.

03 Knowledge check

knowledge check3 questions · pass ≥ 70%

01easy
A design token is…
02easy
Supporting light and dark mode is mostly a matter of overriding the colour tokens.
03medium
Which component kit gives you unstyled, accessible primitives you style yourself?

04 Interview questions

browse all ↗

What gets asked on this topic — tap a card for how to approach it, the follow-ups, and the trap. Company tags are best-effort & sourced.

Commonly asked junior concept occasional What is a design token, and why reference one instead of a raw hex or pixel value?
A design token is a named design value — --accent, --space-4, --radius — that you reference everywhere instead of hardcoding #3fb950 or 16px. The payoff is consistency (everything points at one source, so nothing drifts) and changeability (a rebrand or a dark mode is a token edit, not a find-and-replace). Semantic names (--text, --accent) survive a theme switch in a way raw values can't. It's also the single most useful instruction to give an AI: 'match our tokens'.
What a strong answer covers
- A token is a named value referenced instead of a raw hex/px.
- Consistency: one source of truth, no drift.
- Changeability: theming/rebrand is a token edit, not search-replace.
- Semantic names (--accent, --text) survive theme changes.
Follow-ups they push on
- How does theming (light/dark) fall out of tokens almost for free?
- Why is 'match our tokens' a strong instruction to an AI?
Red flag Letting hardcoded values creep in alongside tokens — they won't theme and they quietly break the scale.
source: CSS-Tricks — What Are Design Tokens? ↗