Design systems

A design system is a living set of standards — tokens, components, patterns, and guidelines — that helps teams design and build consistently at scale. It reduces duplicated work, aligns visual and interaction language, and speeds up delivery when paired with production-ready code.

Why it matters

NN/g describes design systems as the parent layer that contains style guides, pattern libraries, and component libraries. Without shared standards, large organisations accumulate inconsistent UI, messy code, and slower collaboration between design and engineering.

Key ideas

Build from real needs. Include components and patterns the product actually uses — avoid over-engineering unused pieces.
Foundations first. Colour, typography, spacing, radius, and elevation tokens give everyone the same building blocks.
Components with states. Document purpose, variants, anatomy, and accessibility for each component.
Patterns compose components. Forms, navigation, feedback, and empty states are recurring solutions worth standardising.
Content standards belong inside. NN/g recommends integrating UX writing rules into the system so copy and UI evolve together.
Living documentation. Systems must update as the product learns; stale libraries erode trust.

How it fits the pipeline

Design systems codify UI decisions into reusable tokens and patterns as products scale.

Common mistakes

Creating a system disconnected from actual screens in the UI plan
Tokens without concrete values developers can use
Components documented without accessibility guidance
Treating the system as a one-off deliverable instead of a maintained product

Design systems

Why it matters

Key ideas

How it fits the pipeline

Common mistakes

Further reading (NN/g)