5 exercises — learn design token types, the primitive → semantic → component tier model, naming conventions, and export formats.
0 / 5 completed
1 / 5
Match each design token type to what it stores:
1. Colour token · 2. Typography token · 3. Spacing token · 4. Border radius token · 5. Shadow token · 6. Motion token
Design token types — the categories of design decisions that get systematised into named, reusable tokens rather than hardcoded per-component:
• Colour tokens — `$color-primary-500`, `$color-text-error` — every colour used in the product • Typography tokens — font family, size, weight, line-height, and sometimes letter-spacing, often bundled into a single "type style" token like `$font-heading-lg` • Spacing tokens — the constrained scale of padding/margin/gap values (`$space-1` = 4px, `$space-2` = 8px, etc.) • Border radius tokens — corner rounding (`$radius-sm` = 4px, `$radius-full` = 9999px for a pill shape) • Shadow / elevation tokens — drop shadow definitions used to communicate depth/layering (`$shadow-md` = "0 4px 6px rgba(0,0,0,0.1)") • Motion tokens — standardised durations (`$duration-fast` = 150ms) and easing curves (`$ease-standard` = cubic-bezier(0.4,0,0.2,1)) so animation feels consistent product-wide
Tokenising every one of these categories — instead of letting engineers pick arbitrary values per component — is what makes a product feel visually and behaviourally coherent at scale.
2 / 5
What is the three-tier token model: primitive → semantic → component?
The primitive → semantic → component token tier system — the industry-standard architecture for scalable design tokens, because it decouples "what value is this" from "what does this value mean" from "where is this value used."
• Primitive (or "base"/"reference") token — a raw value with no context: `$blue-600 = #2563eb`, `$space-4 = 16px`. Just data, no meaning. • Semantic (or "alias") token — assigns meaning to a primitive: `$color-text-error = $red-600`, `$color-surface-hover = $gray-100`. This is the layer that changes between light and dark mode — the semantic name stays the same, but which primitive it points to flips. • Component token — the most specific layer, scoped to one component's one property: `$button-background-primary = $color-action-primary`. Lets a single component be restyled without touching the semantic layer used everywhere else.
Why three tiers instead of one: if every component referenced primitive colours directly, a rebrand (changing the blue) would require updating hundreds of components. With the tiered model, you change one primitive value, and everything referencing it through the semantic/component chain updates automatically.
3 / 5
Read this token definition and explain what it means:
"The semantic token `$color-text-error` maps to `$red-600` in light mode and `$red-400` in dark mode."
Theming via semantic tokens — this is exactly why the primitive/semantic separation exists: a component or engineer only ever references `$color-text-error`, and never needs to know or care whether the app is in light or dark mode — the token system resolves the correct primitive value automatically based on the active theme.
Why the specific primitives differ by mode: colours that read well on a white background (typically more saturated, mid-value colours like `$red-600`) can look muddy or low-contrast on a dark background, so dark mode themes usually shift to lighter, sometimes desaturated variants (`$red-400`) to maintain sufficient contrast against the darker surface.
This mapping — one semantic name resolving to different primitives per theme — is exactly how multi-theme systems (light/dark, high-contrast, brand-specific themes) work without needing to duplicate every component's styling logic. The engineer writes `color: var(--color-text-error)` once; the CSS custom property's resolved value is swapped by the theme, not the component code.
4 / 5
Which naming convention below correctly follows standard design token structure (category-role-scale, or category-context)?
Design token naming conventions — consistent, structured names make tokens searchable, predictable, and self-documenting, unlike ad hoc descriptive names.
Common naming patterns: • `$color-primary-500` — category (`color`) + role (`primary`) + scale step (`500`, following a numeric scale like Tailwind's 50-950 convention, where higher numbers are typically darker) • `$color-text-default` — category (`color`) + usage context (`text`) + variant (`default`, vs. `muted`, `error`, `success`) • `$button-background-primary` — component-level token: component (`button`) + property (`background`) + variant (`primary`)
Why this matters: `$reallyDarkBlueForButtons` breaks the moment the colour is reused somewhere that isn't a button, or is no longer "really dark," or the design changes to a different blue — the name lies about what it references. Structured, role-based names (`$color-action-primary`) describe the token's purpose, not its literal appearance, so the underlying value can change (a rebrand, a theme) without the name becoming inaccurate or misleading.
5 / 5
What is the purpose of the W3C Design Tokens Community Group (DTCG) format?
W3C Design Tokens Community Group (DTCG) format — an open specification effort (part of the W3C, the same standards body behind HTML/CSS) to define a common, tool-agnostic JSON structure for design tokens, so the design tooling ecosystem isn't fragmented by every vendor using an incompatible proprietary export format.
Why this matters in practice: before a shared standard, a token exported from Figma's "Variables" feature might use a completely different JSON structure than one exported from a plugin like Tokens Studio, forcing teams to write custom conversion scripts for every tool combination. A DTCG-compliant token file looks roughly like: `{"{ \"color\": { \"primary\": { \"$value\": \"#2563eb\", \"$type\": \"color\" } } }"}`` — using `$value` and `$type` as reserved keys that any compliant tool can parse.
Adjacent tooling vocabulary: • Style Dictionary — a popular open-source build tool that transforms a single token source file into every platform's native format (CSS, Swift, Android XML, JSON) in one build step • Tokens Studio — a widely used Figma plugin for managing tokens directly inside Figma with support for the DTCG format
Standardisation here means a design token pipeline can be built from interoperable pieces rather than being locked into one vendor's ecosystem end-to-end.
What will I practice in "Design Tokens Vocabulary — Product Design Exercises"?
This is a Product Design exercise set. It walks through 5 scenario-based multiple-choice questions built around real usage of product design terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 5 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the product design vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Product Design exercises?
See the Product Design exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — product design vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.