Design system

What it is

The term became mainstream through work at Salesforce (Lightning), IBM (Carbon), GitHub (Primer), Google (Material Design) and Shopify (Polaris) between 2014 and 2018. Brad Frost's Atomic Design (2016) formalised the component-hierarchy approach most systems use.

A mature design system contains: design tokens (colour, spacing, type, radius variables defined once, consumed everywhere); components (buttons, inputs, modals, tables, with variants); patterns (compositions of components for recurring use cases — forms, filters, empty states); documentation (how, when, why to use each piece); and governance (who owns the system, how changes propagate, how contributions work).

Why it matters

Without a design system, every product team re-solves the same problems — building their own button, their own form, their own modal — inconsistently. The result is cognitive load for users (every page feels like a different app), engineering waste (same component built N times), and accessibility risk (each ad-hoc build has its own WCAG failures). Design systems scale design by solving these once.

When to use it

A design system earns its place when the organisation has more than two product teams sharing a brand, or one team working on more than three surfaces. Below that, the maintenance cost of the system exceeds the time it saves. Above it, the cost of not having one accumulates fast.

What it looks like in practice

Mature design systems are measured by adoption (what percentage of UI uses the system vs. custom code), consistency (do the same patterns appear across products), and contribution velocity (how fast new patterns move from product teams into the shared library).

The design system team's role is editorial and curatorial, not gate-keeping. Teams that treat design systems as a review bottleneck lose adoption; teams that treat them as a service — fast guidance, pragmatic approvals, clear deprecation paths — gain adoption.

Pair design system work with the accessibility audit methodology — components in the system should pass WCAG 2.2 AA so every consuming product inherits conformance.

What people get wrong

• Treating the design system as a visual style guide. The hard part is the behaviour, states, edge cases, and composability — not the colour swatches.
• Launching with insufficient documentation. Components without usage guidance either get used wrong or don't get used at all.
• No governance model. Who approves changes? Who deprecates? Who notifies downstream consumers? Without answers, the system drifts.
• Ignoring accessibility at the component level. Fixing it in every consuming product is multiplicatively more expensive than fixing it once in the system.

Learn next

Design systems intersect with every other UX discipline — IA (navigation components), content design (copy standards), accessibility (component conformance), interaction design (state and motion patterns). The system is often where UX work scales from craft to product.

Reviewed 1 October 2026 · Editorial standards