6 exercises — learn the vocabulary of design system anatomy: tokens, foundations, primitives vs. semantic components, variants, slots, and atomic design.
0 / 11 completed
1 / 11
A colleague says: "That component isn't in our library yet — open a proposal in the design system repo." What is a "design token"?
Design token — the atomic unit of a design system. A token stores a raw or semantic value under a name, e.g. color.brand.primary = #0A66C2 or space.4 = 16px, so the same decision can be consumed consistently by CSS, iOS (Swift), and Android (Kotlin/XML) without duplicating magic numbers.
Design system anatomy — key vocabulary: • Design tokens — the raw design decisions (colour, spacing, type scale, radius, shadow) • Foundations — the base rules built from tokens: colour palette, typography scale, spacing scale, grid • Component library — the reusable, coded UI components (Button, Input, Modal) built on top of foundations • Patterns — recurring combinations of components that solve a common problem (a search-with-filters pattern, an empty-state pattern) • Guidelines — the written documentation explaining when and how to use each component or pattern
Saying "that's not in our library yet, open a proposal" reflects real design system governance: components are added deliberately, not ad hoc, to keep the system consistent.
2 / 11
Fill in the blank with the correct term:
"The `Button` component has four ___: primary, secondary, ghost, and destructive."
Variant — a distinct, named version of a component that differs in visual style or purpose while sharing the same underlying structure. "Primary, secondary, ghost, destructive" are variants because each communicates a different level of visual emphasis or intent (destructive = a dangerous action like "Delete account").
Do not confuse variant with state: • Variant — a deliberate design choice made by whoever places the component ("I want the primary variant here") • State — a temporary condition triggered by user interaction or system status: default, hover, focus, active, disabled, loading, error
So the full sentence would read: "The Button component has four variants (primary/secondary/ghost/destructive), each of which supports six states (default/hover/focus/active/disabled/loading)." Variant × state is exactly the matrix a component library must design and document.
3 / 11
What is the difference between a "primitive" component and a "semantic" component in a design system?
Primitive vs. semantic — one of the most important distinctions in design system architecture:
• Primitive component — general-purpose, unopinionated: Box, Stack, Text, Flex. Exposes raw styling props (padding, colour, font size) with few constraints. • Semantic component — composed from primitives, but carries meaning and enforces rules: ErrorMessage (always red, always has an icon), PriceTag (always uses the tabular-number font variant), DangerButton (always uses the destructive variant + confirmation dialog).
Why the distinction matters: semantic components prevent misuse ("you can't accidentally make an ErrorMessage green") while primitives give designers/engineers flexibility for one-off layouts that don't deserve a named component yet. A mature design system layers semantic components on top of a small, stable set of primitives — this is sometimes called the "primitive → semantic → component" token tier, mirrored at the token level too.
4 / 11
Match each atomic design term to its correct definition:
1. Atom · 2. Molecule · 3. Organism · 4. Template · 5. Page
Atomic design (Brad Frost, 2013) is a mental model for describing UI complexity in five tiers:
1. Atoms — smallest building blocks: a button, an input, a label, an icon. Cannot be broken down further without losing function. 2. Molecules — simple groups of atoms functioning as a unit: a search field is an atom-input + an atom-button. 3. Organisms — more complex, distinct sections of an interface made of molecules and atoms: a site header (logo + nav + search molecule). 4. Templates — page-level layout structures that arrange organisms, using placeholder/lorem-ipsum content to show structure without final content. 5. Pages — specific instances of a template with real content, used to test how the design system actually looks in production.
You will hear this vocabulary in design reviews: "Is this an atom or should it be a molecule?" is really asking whether something should be its own reusable component or is just a one-off composition.
5 / 11
A designer writes in a Slack thread: "This component needs a `slot` for a trailing icon." What does "slot" mean here?
Slot — a named insertion point inside a component's structure where the consumer (the person using the component) can pass in their own content — an icon, a custom label, a badge — without editing the component's internal code or design.
Example: a `Card` component might expose slots for header, media, and footer. Someone using the Card can fill the `footer` slot with a price, a date, or a button — the Card component itself doesn't need to know what goes there.
Related vocabulary: • Prop (short for "property") — a value passed into a component to configure it, e.g. size="large" or disabled={"{true}"} • Slot vs. prop — a prop is usually a simple value (string, boolean, number); a slot accepts arbitrary content, including other components • In Figma, the equivalent concept is an instance swap property or a nested component that the user can override
Saying "this needs a slot for X" is precise design-system language for "make this part of the component configurable/replaceable," rather than hard-coding it.
6 / 11
What is the correct process, according to standard design system governance vocabulary, described by: "To add a new component, open a proposal in the design system repository"?
Design system governance — the process and vocabulary around deciding what gets added to (or changed in) a shared design system:
• Proposal / RFC (Request for Comments) — a written document describing a new component or change, submitted for review before implementation • Contribution model — federated (many teams contribute components) vs. centralized (one core team owns the system) • Design system team / working group — the people responsible for reviewing proposals, maintaining consistency, and preventing "component sprawl" (many near-duplicate components solving the same problem slightly differently) • Deprecation — the formal process of marking an old component/token as no longer recommended, with a migration path to its replacement • Adoption rate — the metric tracking how much of the product actually uses design system components vs. one-off custom UI
"Open a proposal" signals that design systems are treated like shared infrastructure — changes go through review, just like a pull request to a shared codebase, because a change ripples across every team that consumes the system.
7 / 11
Reviewer: 'The `input-field` component uses the `color-palette--primary` design token. Could you clarify if that's still the intended usage after the recent branding update? It seems a bit dated now.' What is color-palette--primary?
Design tokens are named values (like colors, fonts, spacing) that provide consistency across a design system. They're not just CSS classes; they represent the *concept* of a color – and allow you to update the value centrally while ensuring all instances use it correctly. Option A is incorrect because it describes a CSS class, not the underlying concept represented by the token.
8 / 11
You're writing the description for a Pull Request that adds a new `card` component to the design system. Which of the following best describes the purpose of including the term 'design system' in your PR description?
When discussing a PR related to a design system, emphasizing its adherence to those guidelines is crucial. Including 'design system' in the description clarifies that the component isn't just any UI element; it's built according to established principles and standards for consistency and maintainability within the broader system. Options A, B, and D are irrelevant to the core purpose of a design system PR.
9 / 11
A teammate sends this Slack message: 'Hey @johndoe, I'm using the `spacing-scale--small` token for this button's padding. Just wanted to make sure we're consistent with the overall spacing system.' What is a 'spacing scale'?
A 'spacing scale' is a fundamental concept within many design systems – it's a standardized system for defining distances between UI elements. These scales are typically defined using *design tokens*, and their consistent use ensures visual harmony across the entire product. Option C is incorrect as it refers to UX principles, not the definition of a spacing scale.
10 / 11
You're querying an API endpoint that returns design system data. The response contains this JSON snippet:
{
"token": "color-palette--primary",
"value": "#ffffff",
"description": "The primary color for the application."}
What does the 'token' field represent?
The 'token' field within this API response represents a *unique identifier* for a particular design token. This allows you to easily reference and manage that token across your codebase – it's not just the value itself, but how that value is identified and associated with its definition. Options A, C, and D are incorrect because they describe different aspects of the API or system management.
11 / 11
"Sarah: I'm working on creating a new `form-element` component. I've documented all the design tokens it uses in the design system documentation – specifically focusing on how they relate to accessibility standards." What is Sarah communicating about within this update?
Sarah's update emphasizes a core principle of design systems: ensuring that components are built using consistent tokens *and* that those tokens align with important considerations like accessibility standards. By focusing on how tokens relate to accessibility, she's demonstrating an understanding of the broader system goals – it's not just about building a component, but about contributing to a usable and compliant product.
What will I practice in "Design System Vocabulary — Product Design Exercises"?
This is a Product Design exercise set. It walks through 11 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 11 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.