UX9: Design systems and handover
Components and their states
🎯You'll be able to
Define a small set of components, each with its variants and states, built from tokens.
🏠The everyday picture
A modular kitchen is built from a few standard units: base cabinets, wall cabinets, drawers. Each comes in a few sizes and finishes. Any kitchen can be made from them, and every unit fits.
📘What it really is
- A component is a reusable part of the interface with a defined purpose: button, text field, time slot, alert.
- Variants are deliberate versions: primary and secondary buttons; error and success alerts.
- States are conditions the component can be in (UX8): default, hover, focus, selected, disabled, loading, error.
- Built from tokens: a button's colour, padding, radius and type all come from tokens.
- Accessibility built in: the component includes its role, name rules, focus style and minimum size, so every team gets them.
-
Few and solid: a small system that covers real needs beats a large one nobody understands. Add components when several screens need them, not before.
-
Use the system: every button in the product uses the button component. The kit's test 9 checks that every
<button>in the prototype has thebtnorslotclass.
📝A worked example
Input: the reference time slot component.
| Part | Decision |
|---|---|
| Element | <button type="button" class="slot" aria-pressed="false"> |
| Size | at least 48 pixels high, full grid cell wide |
| Default | primary-coloured text and border on the surface colour |
| Selected | filled with primary, white text, a tick before the time, aria-pressed="true" |
| Focus | 3 px outline in --color-focus |
| Disabled (booked) | disabled colours, disabled attribute, hidden word "booked" |
Expected output: the component page shows all four states, and test 6 of npm run test:system finds each one.
🌍Where it's used
- Public design systems from governments and large companies, used by many teams.
- Component libraries in code (for example in React, Module 32) that mirror the design components.
- Design-tool libraries with variants and properties.
📝Case scenario
A retail company had 37 different button styles across its apps. An audit grouped them into two variants and five states. Building screens got faster, and accessibility fixes made once in the button reached every app.
🖱️Try it
List the components you'd need for SehatSlot's "My appointments" screen (which the kit doesn't have yet). Success: you reuse at least three existing components and propose at most one new one, with its states.
⚠️Common mistakes
- One-off components. Sign: a special button for one screen. Fix: use a variant, or add one deliberately.
- States missing. Sign: no disabled or loading design. Fix: list states for each component.
- Accessibility left to each team. Sign: some buttons have focus styles, others don't. Fix: put it in the component.
🛠️For your project
Project 3's component page must show button, text field, time slot and alert in every required state.
✅Quick check
What is the difference between a variant and a state?
Show the answer
A variant is a deliberate version (primary or secondary); a state is a condition it can be in (focus, disabled, loading).
Why build accessibility into components?
Show the answer
So every team that uses them gets it automatically.