Explain what a design system contains and why teams build one, then audit a real interface for inconsistency.
Why it matters
As a product grows, small inconsistencies pile up. One team's button has 4px corners, another's 8px. There are eleven shades of grey, three date pickers and two different error styles. Each one was a reasonable decision on the day, but together they make the product feel unreliable, slow designers down ("which button do I use?") and multiply engineering work, because every variation has to be built, tested and maintained.
A design system is how teams stop that drift. Knowing how to use, extend and argue for one is a core mid-level skill: most product design jobs today involve working inside a system rather than designing every screen from scratch.
The core idea: shared decisions, written down and built once
A design system is a collection of reusable decisions, with the code and documentation that make them easy to follow. It usually has these layers:
| Layer | What it is | Example |
|---|---|---|
| Principles | The values that guide decisions | "Clear over clever" |
| Design tokens | Named values for colour, type, spacing, radius, shadow, motion | color-primary, space-4 |
| Components | Reusable UI parts with states and variants | Button, Input, Modal |
| Patterns | Combinations of components for common jobs | Sign-in form, empty state |
| Documentation | When and how to use each piece | Usage guidelines, do and don't |
| Code library | The components implemented for developers | A React or web component package |
| Governance | How changes are proposed, reviewed and released | Contribution process, versioning |
A style guide (colours and fonts) or a UI kit (a Figma file of components) is part of a system, not the whole thing. A system only works when design and code match and people know how to contribute.
Well-known public systems are worth studying: Google's Material Design, IBM's Carbon, the UK government's GOV.UK Design System, Shopify's Polaris and Atlassian's design system all publish their tokens, components and guidelines for free.
What a system buys you
- Consistency: users learn a pattern once and recognise it everywhere.
- Speed: designers assemble screens from tested parts; developers reuse code.
- Quality: accessibility, states and edge cases are solved once in the component.
- Easier change: update a token, and every screen that uses it updates.
The cost is real too: someone has to maintain it, and a system that is too rigid or out of date gets ignored. Small teams often start with tokens and a handful of core components, not a full system.
The interface inventory (UI audit)
The classic way to start, or to justify, a design system is an interface inventory: collect every instance of each UI element across the product and put them side by side. Brad Frost popularised this approach. The visual evidence ("we have 14 button styles") persuades teams far better than any argument.
How to run one:
- Choose the scope: a product, or the five to ten most-used screens.
- Pick categories: buttons, form inputs, colours, type styles, icons, spacing, cards, alerts and messages, modals.
- Screenshot every instance and crop it. Paste each category onto its own board (paper, slides or free Figma).
- Group duplicates and count the variations.
- Note the differences that matter: size, colour, corner radius, label style, states.
- Recommend a consolidated set: for example, "3 button variants (primary, secondary, danger) in 2 sizes".
Worked example: a small audit
An audit of a booking site's top eight screens found:
| Category | Variations found | Notes | Proposed |
|---|---|---|---|
| Primary buttons | 6 | 3 blues, radius 2/4/8px, 36 to 52px tall | 1 style, 2 sizes |
| Greys used for text | 9 | Several fail contrast on white | 3 text greys |
| Error messages | 4 | Red text, red box, toast, alert icon only | 1 inline pattern + 1 page alert |
| Date pickers | 3 | Two custom, one native | 1 accessible picker |
| Font sizes | 13 | 11px to 40px with no scale | 7-step type scale |
This table, plus the boards of screenshots, became the case for building tokens (next lesson) and a small component library.
Common mistakes
- Starting with a huge library. Build what the product actually uses; grow from real needs.
- Design-only systems. A Figma kit that does not match the code creates two sources of truth.
- No owner. Without governance, the system drifts like the product did.
- Auditing opinions instead of instances. Collect what exists before deciding what is "right".
- Treating the system as a rulebook only. It should make the right choice the easy choice, with clear docs and a way to propose changes.
Quick recap
- A design system is shared, reusable decisions: tokens, components, patterns, docs, code and governance.
- It buys consistency, speed, quality and easier change, at the cost of maintenance.
- An interface inventory collects every instance of each UI element to show inconsistency and guide consolidation.
Try it
On the Do tab you will run an interface inventory on a real product and propose a consolidated set of components.