Lesson 7 of 30

Design Tokens & Consistency at Scale

Q: A product needs a rebrand that changes the primary color. Walk me through how a token-based system handles that versus one that doesn't use tokens.

A strong answer covers: Without tokens: every hardcoded hex value needs to be found and replaced across the codebase, which is error-prone and easy to miss instances of; With tokens: updating the semantic token's definition once propagates to every component that references it; Distinguish primitive tokens (raw values) from semantic tokens (a role assigned to a primitive) — components should consume semantic, not primitive, tokens.

A hardcoded hex value is a decision made once and repeated by hand forever. A token is that same decision named and centralized — the difference between a color and a system.

13 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

What's the difference between a primitive token and a semantic token?

A primitive is a raw value with no meaning yet; a semantic token points at a primitive and assigns it a roleA primitive token can only be a color; a semantic token can be any value typeThere's no real difference — the two terms describe the same thing in different design systems

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Design Tokens & Consistency at Scale

What interviewers actually ask about this, and what a strong answer has to cover.

A product needs a rebrand that changes the primary color. Walk me through how a token-based system handles that versus one that doesn't use tokens.

A strong answer covers

Without tokens: every hardcoded hex value needs to be found and replaced across the codebase, which is error-prone and easy to miss instances of
With tokens: updating the semantic token's definition once propagates to every component that references it
Distinguish primitive tokens (raw values) from semantic tokens (a role assigned to a primitive) — components should consume semantic, not primitive, tokens

Likely follow-ups

How does a dark/light theme toggle relate to this same token structure — what has to change, and what doesn't?
Should every single CSS value in a codebase become a named token? Why or why not?

Practice these with the AI interviewer →

The plain-language idea

A design token is a named, centralized value standing in for a raw design decision — a color, a spacing value, a font size, a radius. Instead of every component writing background: #00d89d, every component writes background: var(--color-accent), and one file decides what --color-accent actually is.

The reasoning trio from the last three lessons — type scale, spacing scale, color — are exactly what tokens are for. A scale is a set of related values; a token is the name that lets a component reach for one of those values without knowing or caring what it currently resolves to.

Most real systems split tokens into layers:

Primitive tokens — raw values with no assigned meaning yet (--p-neutral-950: #0a0b0e).
Semantic tokens — a primitive given a role (--color-bg: var(--p-neutral-950) — "this primitive is now the page background").
Component tokens (sometimes skipped in smaller systems) — a semantic token scoped to one component's specific need (a button's own background, which might reference the semantic accent but could diverge later without touching the accent itself).

See it in a real thing: this app's own three layers

Token layers: primitive → semantic → componentStep 1 of 3

A primitive token: a raw value with no meaning attached yet — just a color.

This platform's own globals.css is a real, live instance of exactly this structure — and it's not an accident that "components consume ONLY semantic + track tokens, never primitives" is written into this codebase as an enforced rule, not a suggestion. A component that reached past the semantic layer straight to --p-jade-500 would still work today — and would silently stop tracking any future retheme, because the semantic layer is the only thing anyone promises to keep updated.

/* Primitive: a raw value, no meaning yet */
--p-jade-dark: #00d89d;

/* Semantic: the primitive given a role */
--color-accent: var(--p-jade-dark);

/* Component consumes the role, never the primitive */
.button { background: var(--color-accent); }

What people usually miss

Watch out

Tokens aren't just about color. Spacing, radius, type scale, shadow, motion duration, and z-index all benefit from the same primitive → semantic pattern — a --z-modal token prevents the same "what number is safely above everything else" guessing game that untamed hex values create for color.
The semantic layer is what makes theming (including dark/light mode) close to free. This platform's own light/dark toggle works by having the semantic layer's values change per theme while every component keeps referencing the same semantic names — no component needed to know a theme toggle would ever exist.
A token system doesn't remove judgment — it relocates it. Someone still decides what --color-accent equals. Tokens don't make design decisions disappear; they make each decision get made exactly once, in exactly one place, instead of once per component.
Not every one-off value should become a token. A token is for a value that's reused or that represents a real, recurring role. A single component's unique, non-repeating adjustment doesn't need a named token — turning every value into a token just relocates the "arbitrary number" problem into the token list instead of solving it.

Why this matters in interviews

"How would you handle a rebrand that changes the primary color?" is a real, common systems-thinking question. "Find every hex value and replace it" is the answer of someone who hasn't used tokens. "Update the semantic accent token once" is the answer of someone who has — and it's a difference interviewers specifically listen for.