What design tokens are and why they matter

WHAT THIS TESTS: This checks whether you understand design tokens as an abstraction layer for design decisions and the maintenance and consistency problems they solve.

A GOOD ANSWER COVERS: A design token is a named representation of a design decision, for example color-brand-primary, font-size-body, or space-200, stored in a central, platform-neutral format like JSON. Instead of hard-coding #6344D6 in dozens of files, you reference the token. The benefits are consistency, since one definition feeds every component and platform; maintainability, since changing the token updates everywhere at once; theming, since light and dark or multi-brand variants swap by remapping token values; and cross-platform reach, since the same source can be transformed into CSS variables, Swift, Kotlin, and more. Tokens also encode intent and form a shared vocabulary between designers and engineers, often layered into primitive, semantic, and component tiers so that semantic tokens like color-text-default point at primitives like gray-900.

COMMON WRONG ANSWERS: Saying a token is just a CSS custom property; a custom property is one output of a token, but the token itself is platform-agnostic. Claiming the only benefit is avoiding repetition, missing theming and multi-platform distribution. Ignoring the primitive versus semantic distinction.

LIKELY FOLLOW-UPS: How do you tier tokens into primitive, semantic, and component levels. What tooling transforms tokens into per-platform formats. How does the W3C Design Tokens format standardize the JSON shape.

ONE CONCRETE EXAMPLE: Define space-md once as 16px in a token file. Web builds turn it into --space-md, iOS into a Swift constant, and Android into a dimension resource. Bump it to 18px in the source and every platform updates on the next build, with no per-file edits.