My progress
Menu

UI/UX Product Designer · Focus area 3: Interactive prototypes

UX9: Design systems and handover

Goal: capture design decisions as tokens, build components with every state, document them so developers can use them correctly, hand designs over clearly and check the build, and keep the system versioned and looked after.

You'll need: UX6 to UX8, Module 25 (APIs and JSON) for reading tokens.json, Module 32 (Components and Props), and the SehatSlot practice kit (design-system/ and tools/build-tokens.js).

Where this is used: a company with ten teams building screens can't have each choose its own blue, its own button and its own error style. A design system is the shared set of decisions and parts that keeps products consistent, accessible and quicker to build.

How it differs: designing a screen solves one problem. A design system solves the same problem for many screens and many teams, so it needs naming, documentation, versions and someone to look after it.

Time: reading about 2 hours · practice (the Try it tasks) about 3 hours · assignment about 4 hours.

Lessons

  1. 1Design tokensReading 15–25 minutes, plus practice✓
  2. 2Components and their statesReading 15–25 minutes, plus practice✓
  3. 3Documentation people can useReading 15–25 minutes, plus practice✓
  4. 4Handover and checking the buildReading 15–25 minutes, plus practice✓
  5. 5Versioning and looking after the systemReading 15–25 minutes, plus practice✓

🛠️Assignment: Build and hand over SehatSlot's design system

  1. Fix design-system/tokens.json: purpose-based names, contrast pairs, focus colour and a spacing scale; run npm run tokens.
  2. Replace every raw colour in prototype/styles.css with tokens.
  3. Build the component page with every state of button, text field, time slot and alert.
  4. Write the README with When to use, Don't and Accessibility for each component.
  5. Write a handover note for one screen, with acceptance criteria.
  6. Choose the new version number and write the changelog.

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

How does a design system help many teams build consistent, accessible screens?

Show a good answer

A good answer mentions: tokens named by purpose as the single source of truth, generated into code and checked for contrast and spacing; a small set of components with variants and every state, with accessibility built in; documentation with when to use, don't and accessibility, and live examples; handover with components, tokens, states, behaviour, content and testable acceptance criteria, followed by design QA; and semantic versioning, a changelog and clear ownership.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. A token is named color-teal-500 and used for error messages. What's the problem?

Why each option is right or wrong

  • “Token names have to include a number, and 500 is too high for errors” (Incorrect): Numbers aren't required; the issue is the meaning.
  • “Teal is not a valid colour in the CSS colour specification at all” (Incorrect): It's valid; naming is the problem.
  • “Error colours have to be defined separately from all other colours” (Incorrect): They can be in the same group with a clear name.
  • “It's named by its look, so the name is wrong once the colour changes” is correct.

    Purpose-based names (color.error) stay right when the shade changes.

    • Also: teal for errors is unusual and confusing.
    • Kit: --color-error.

📖 Revise: Lesson 1: Design tokens

Question ID sp-ui-ux-09-q1 · Report a mistake in this question
2. A developer edits prototype/tokens.css by hand to fix a colour. What happens next time someone runs npm run tokens?

Why each option is right or wrong

  • “Nothing, since the build script reads the CSS file before writing it” (Incorrect): It reads tokens.json, not the CSS.
  • “The build script refuses to run until the hand edit is removed” (Incorrect): It doesn't check; it overwrites.
  • “The colour is merged automatically into the JSON token file” (Incorrect): The script only writes CSS from JSON.
  • “The hand edit is lost: the file is rebuilt from tokens.json” is correct.

    tokens.json is the source of truth; the fix belongs there.

    • Kit: test 5 catches a stale tokens.css.
    • Header: "Don't edit by hand".

📖 Revise: Lesson 1: Design tokens

Question ID sp-ui-ux-09-q2 · Report a mistake in this question
3. One screen has a special button style used nowhere else. What should the design system team do?

Why each option is right or wrong

  • “Add it as a new component straight away, since a team needed it” (Incorrect): One-off needs usually fit an existing variant.
  • “Ignore it, as teams can style their own screens however they like” (Incorrect): That's how systems drift into dozens of button styles.
  • “Ask every team to switch to the special style, so it's consistent” (Incorrect): Changing everyone's buttons for one screen isn't sensible.
  • “Check if an existing variant fits; add one only if several screens need it” is correct.

    A small system covers real needs; additions are deliberate.

    • Test: every <button> uses btn or slot (kit test 9).
    • Process: a proposal and review.

📖 Revise: Lesson 2: Components and their states

Question ID sp-ui-ux-09-q3 · Report a mistake in this question
4. A component's documentation says only "Teal, white text." What's missing most?

Why each option is right or wrong

  • “A larger screenshot of the button, in high resolution” (Incorrect): A screenshot still doesn't say when to use it.
  • “The exact hex codes for teal and white, in the README” (Incorrect): Those are in the tokens; guidance is what's missing.
  • “The name of the designer who created the button component” (Incorrect): Ownership matters for the system, not for each component's usage.
  • “When to use it, when not to, and how it works for accessibility” is correct.

    Developers need guidance on use and behaviour, not just looks.

    • Kit: test 8 checks all three sections.
    • Add: live examples.

📖 Revise: Lesson 3: Documentation people can use

Question ID sp-ui-ux-09-q4 · Report a mistake in this question
5. A handover file shows every screen in its default state only. What's the likely result?

Why each option is right or wrong

  • “Developers will build exactly what the designer had in mind” (Incorrect): They'll have to guess the other states.
  • “The product will launch earlier, since there's less to build” (Incorrect): The states are still needed; they're just undesigned.
  • “Users won't notice, since states are rarely seen in practice” (Incorrect): Errors, empty results and loading happen often.
  • “Developers invent error, empty and loading states themselves” is correct.

    Missing states get filled in under time pressure, often with unclear wording.

    • Include: every state and its exact words.
    • Plus: acceptance criteria.

📖 Revise: Lesson 4: Handover and checking the build

Question ID sp-ui-ux-09-q5 · Report a mistake in this question
6. Which handover note is most useful to a developer?

Why each option is right or wrong

  • “"Gap between the slots: 12px, colour: #0b5d7a, radius: 8px"” (Incorrect): Raw values bypass the system and drift when tokens change.
  • “"Make it look like the picture in the design file, please"” (Incorrect): It leaves behaviour, states and accessibility to guesswork.
  • “"Slots should feel friendly and modern, but still look professional"” (Incorrect): Not something a developer can build or test.
  • “"Slots: button.slot, gap --space-3, aria-pressed; see test 3"” is correct.

    It names the component, token, state attribute and a testable criterion.

    • Add: the status line's wording.
    • Then: design QA on the build.

📖 Revise: Lesson 4: Handover and checking the build

Question ID sp-ui-ux-09-q6 · Report a mistake in this question
7. A design system renames color.link to color.action. Which version change fits?

Why each option is right or wrong

  • “Patch, since only a name changed and not a colour” (Incorrect): Renames break every use of the old name.
  • “Minor, since new things were added to the system” (Incorrect): Something was removed (the old name), which breaks use.
  • “No version change, as long as the changelog mentions it” (Incorrect): Versions tell teams what to expect; this one breaks.
  • “Major, because code that uses the old name will break” is correct.

    Breaking changes need a major version, notice and a migration guide.

    • Better: deprecate first, remove later.
    • Changelog: explain the rename.

📖 Revise: Lesson 5: Versioning and looking after the system

Question ID sp-ui-ux-09-q7 · Report a mistake in this question
8. Why does the kit's component page use the prototype's real CSS instead of screenshots?

Why each option is right or wrong

  • “Screenshots can't be shown in a web browser on phones” (Incorrect): They can; the issue is drift.
  • “Because screenshots are too large for the repository to hold” (Incorrect): Size isn't the main reason.
  • “Because developers aren't allowed to look at image files” (Incorrect): There's no such rule.
  • “So the examples stay in step with the product” is correct.

    Live examples change when the CSS changes; screenshots go out of date.

    • Also: axe can check a live page (kit test 7).
    • Use: for design QA.

📖 Revise: Lesson 3: Documentation people can use

Question ID sp-ui-ux-09-q8 · Report a mistake in this question
9. Several teams copy the button and change it slightly. Six months later there are nine button styles. What would have helped most?

Why each option is right or wrong

  • “A rule that only the most senior designer may draw any button” (Incorrect): That doesn't scale and doesn't stop copying.
  • “Removing the button component so each team makes its own” (Incorrect): That leads straight to inconsistency.
  • “More colours in the palette so each team has its own option” (Incorrect): More choice makes drift worse.
  • “Clear owners and a review process for proposals” is correct.

    Governance keeps the system shared and stops quiet drift.

    • Also: a changelog and versions.
    • Contribution: propose, review, document, release.

📖 Revise: Lesson 5: Versioning and looking after the system

Question ID sp-ui-ux-09-q9 · Report a mistake in this question
10. What should a design QA review of the built slot screen include?

Why each option is right or wrong

  • “Only a visual comparison of screenshots at one desktop size” (Incorrect): It misses states, phones, keyboard and screen readers.
  • “A check that the code compiles without any warnings” (Incorrect): That's the developers' build check, not design QA.
  • “Asking the developer whether they followed the design” (Incorrect): Useful, but not a review.
  • “Every state at phone size, by keyboard and with a screen reader” is correct.

    Design QA checks behaviour and accessibility as well as looks.

    • Log: differences with expected behaviour.
    • Run: the acceptance tests too.

📖 Revise: Lesson 4: Handover and checking the build

Question ID sp-ui-ux-09-q10 · Report a mistake in this question

ProLearners Assist