← Go Back

Design Systems

What is a design system?

A design system is a single source of truth for design and (often) implementation: reusable components, design tokens (colour, type, spacing), and guidelines so teams can build consistent, accessible products without reinventing the wheel. It’s more than a component library or style guide: it includes principles, patterns, and documentation that govern how products look and behave.

Use it when: you have multiple products, teams, or platforms and need consistency, faster build, and fewer bugs. Start small (tokens + a few components) and grow; don’t wait for “everything” before publishing.

Copy/paste checklist (minimum viable system)

  • [ ] Design tokens – Colour, typography, spacing (and optionally motion, radius) as named variables.
  • [ ] Core components – Buttons, inputs, links, and at least one layout primitive (e.g. stack, grid).
  • [ ] Usage guidelines – When and how to use each component; do’s and don’ts.
  • [ ] Accessibility – WCAG alignment and keyboard/focus behaviour documented.
  • [ ] Code – Implemented components (or clear handoff to dev) so the system is usable in build.
  • [ ] Ownership – Who maintains it; how to propose and adopt changes.

Why design systems matter

  • Consistency across products and teams so the experience feels coherent.
  • Speed: reuse instead of redesign and rebuild for every feature.
  • Quality: shared components are tested once (including accessibility) and improved for everyone.
  • Shared language between design and development so handoff and collaboration are clearer.

What a good design system includes

Checklist

  • [ ] Tokens first – Colours, type, spacing defined as tokens so themes and consistency are manageable.
  • [ ] Documented components – Name, purpose, props/variants, accessibility notes, and code or link to code.
  • [ ] Guidelines – When to use what; patterns (e.g. forms, navigation); content and tone where relevant.
  • [ ] Accessible by default – WCAG considered in components and docs.
  • [ ] Versioned and maintained – So teams can adopt and upgrade; change process is clear.
  • [ ] Used – The system is the default for new work; exceptions are justified.

Common formats

  • Centralised: One team owns and publishes; others consume. High consistency; can be slower to evolve.
  • Federated: Multiple teams contribute with central governance. More flexibility; needs clear ownership and contribution rules.
  • Documentation site: Storybook, custom site, or Notion/Figma so designers and devs can browse and use components.

Examples

Example (the realistic one)

You ship “Design system v0.1”: tokens (primary/secondary colours, type scale, 4px/8px spacing), 5 components (Button, TextInput, Link, Card, Stack), each with usage and accessibility notes in a Storybook. One team owns it; others are encouraged to use it for new features. You add components and patterns as you find repeated needs. Within six months you have 15 components and a “When to use what” page. New products start from the system instead of blank files.

Common pitfalls

  • Building in isolation: the system doesn’t match real product needs. → Do this instead: extract from real screens and flows; involve product teams in prioritising components.
  • No code or no design: only Figma or only code. → Do this instead: keep design and code in sync; at least document both so both disciplines can use it.
  • Ignoring accessibility: components aren’t keyboard-friendly or screen-reader friendly. → Do this instead: build accessibility into components and document it; reference WCAG.
  • Too big a first release: “we’ll launch when we have 50 components.” → Do this instead: ship a small, useful set; iterate based on usage and requests.
  • No ownership: nobody maintains it and it drifts. → Do this instead: assign an owner or small team; define contribution and release process.
  • Design system vs component library: a component library is the set of implemented components; a design system includes tokens, guidelines, and principles as well. The library is part of the system.
  • Design system vs style guide: a style guide is often visual (brand, typography, colour); a design system includes behaviour, components, and usage rules. Style guide can be one part of the system.
  • Design system vs design standards: design standards are the rules and principles; a design system is the concrete implementation (tokens, components, docs) that embodies those standards.
  • Component libraries – the built components in the system.
  • Design standards – principles and rules the system implements.
  • Accessibility – design systems should enforce accessible patterns.
  • WCAG – target level (e.g. AA) for system components.
  • UI design – the system supports consistent UI design.
  • Alignment – design systems support visual and structural alignment across products.
  • Scalability – systems help design and code scale across products.
  • Design tokens – often the foundation of a design system (colour, type, spacing).

Next step

If you don’t have a system, start with tokens (colour, type, spacing) and one or two components (e.g. Button, TextInput) and document them. If you have one, audit one flow for accessibility and ensure the system’s components and docs support WCAG AA.

Related Terms