UX Design Advanced: Systems, Research, Ethics and Career
Design Systems and Components
In this lesson you will
- Explain design tokens, components and patterns
- Document a component with states, usage and accessibility notes
- Describe how to govern and evolve a design system
Introduction
As products grow, many people design and build screens. Without shared rules, buttons slowly become different shades, spacing drifts and every team reinvents the same thing. A design system is the shared language that keeps products consistent, faster to build and easier to make accessible.
What is in a design system
- Principles: the values guiding decisions, such as "clarity over cleverness".
- Design tokens: the named, reusable values for colour, typography, spacing, sizes, radii and shadows.
- Components: reusable interface parts such as buttons, inputs, cards and dialogs.
- Patterns: guidance for solving recurring problems, such as sign-in, search and error handling.
- Content guidelines: voice, tone and writing rules.
- Accessibility guidance built into everything.
- Documentation and code: how and when to use each piece.
Public examples worth studying include the GOV.UK Design System, which is openly documented.
Design tokens
Instead of writing #5b4bf5 in fifty places, define a token named for its purpose:
color.action.primary = #5b4bf5
color.text.default = #111827
space.3 = 12px
font.size.body = 16px
radius.medium = 8pxBenefits:
- Change once, update everywhere.
- Meaningful names ("action primary") explain intent, so a change to the brand colour does not break meaning.
- Support for themes, such as dark mode, by mapping the same names to different values.
- A shared language between design and code.
Check accessibility when you choose tokens: text colours must meet contrast requirements on their backgrounds.
Quick quiz
Why name a token color.action.primary instead of color.purple?
Components
A good component is reusable, consistent and accessible. Document each one with:
- Purpose: what it is for, and when not to use it
- Anatomy: its parts (label, icon, helper text)
- Variants: primary, secondary, destructive
- States: default, hover, focus, pressed, disabled, loading, error
- Behaviour and content rules: text length, wrapping, what to write
- Accessibility: keyboard behaviour, focus, roles, contrast and screen reader text
- Responsive behaviour
- Code and design file links
Design every state, especially focus, disabled, error and empty. These are the ones people forget and users meet.
Build small pieces first (buttons, inputs), then combine them into larger ones (forms, cards), a layered approach often called atomic design.
Building and growing a system
- Start small. Audit your current interfaces, list what repeats, and standardise the most used pieces first.
- Co-create with designers and developers, so it works in code as well as in design files.
- Keep design and code in step. A component that exists only in a design file is not a system.
- Version the system, and publish a changelog.
- Have owners and a process for contributions and requests.
- Deprecate carefully: give teams time and guidance to move.
- Measure adoption and gather feedback.
- Avoid the trap of rigidity. A system should help people do good work faster, not stop them solving real problems. Provide a way to propose exceptions.
Common mistakes
- Building a huge system before there is a need
- Documenting how it looks but not when to use it
- Ignoring accessibility until late
- Letting it go stale with no maintenance
- Making it hard to use for the people who must adopt it
Working with developers
Share the vocabulary and agree names. Review components together, and test real implementations in different browsers, devices and with assistive technology. Treat the system as a product with users: the teams who build with it.
Try it yourself
Audit one product: list every button style you can find and count the differences. Propose five tokens and one documented component (a button) with its states and accessibility notes.
Summary
- A design system combines principles, tokens, components, patterns and guidelines for consistency and speed.
- Tokens name reusable values by purpose, and components document variants, states, behaviour and accessibility.
- Start small, keep design and code in sync, assign owners and treat the system as a maintained product.
Lesson complete
+20 XP
Nice work. Keep going while it is fresh.
Sources and further reading