Why design systems

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 systemA collection of shared, reusable design decisions (tokens, components, patterns, docs, code and governance) that teams build once and reuse. 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:

A style guide (colours and fonts) or a UI kitA design file of components, such as a Figma library; one part of a design system, not the whole thing. (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 patternA combination of components for a common job, such as a sign-in form or an empty state. 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 inventoryAn audit that collects every instance of each UI element across a product and puts them side by side to show inconsistency.: 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:

1. Choose the scope: a product, or the five to ten most-used screens.
2. Pick categories: buttons, form inputs, colours, type styles, icons, spacing, cards, alerts and messages, modals.
3. Screenshot every instance and crop it. Paste each category onto its own board (paper, slides or free Figma).
4. Group duplicates and count the variations.
5. Note the differences that matter: size, colour, corner radius, label style, states.
6. 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:

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.