What is a design system?

A complete set of standards for managing design at scale with reusable components and patterns, as Nielsen Norman Group defines it. It usually covers tokens, components, patterns, written guidelines and the governance that keeps it up to date.

When does a product need a design system?

When you have many screens or several products that you will keep building for years, and the time and people to maintain it. NN/g advises against one for short-lived prototypes and suggests checking open-source systems first.

How much time does a design system save?

In a study Figma published in 2019, designers completed a task 34% faster with a design system than with older design files. The author notes this is likely the maximum saving, because the system was relevant and up to date.

Back to Blog

Guide1 November 20265 min read

How to build a design system

What a design system is made of, when your product needs one and how to build it step by step, with what one study measured.

$Cover for “How to build\na design system”: A design library sheet with colour swatches, a blue button, a toggle, an input field and a card.$

A product manager asks for a new settings screen. The designer opens old files to check which blue the buttons use and finds three. The developer can’t find a reusable button, so they write another one. Two weeks later the screen ships with a fourth blue. Nobody chose badly. There was simply no shared place where the decision had already been made.

What a design system is

Nielsen Norman Group defines a design system as “a complete set of standards intended to manage design at scale using reusable components and patterns.” In practice it has five parts:

Tokens. Named values for small decisions that repeat everywhere: colours, type sizes, spacing, corner radius. Atlassian describes them as “name and value pairings that represent small, repeatable design decisions”, for example a token called color.icon.success instead of a specific shade of green. In October 2025 the W3C Design Tokens Community Group published the first stable version of a shared format (version 2025.10), so that design tools and code can exchange tokens.
Components. Reusable interface elements such as buttons, text fields and menus, each with a name, its states and working code.
Patterns. Combinations of components that solve a recurring task, such as a sign-in form or a page template.
Guidelines. Written rules on when to use what, how to write labels and what accessibility requires.
Governance. The people and process that keep it alive. NN/g puts the minimum team at an interaction designer, a visual designer and a developer, ideally with an executive sponsor.

Well-known public examples include Google’s Material Design, IBM’s open-source Carbon, Shopify’s Polaris and the GOV.UK Design System used across UK government services.

A useful mental model comes from Brad Frost’s book Atomic Design (2016). Borrowing from his school chemistry lessons, he breaks an interface into atoms (a label, an input, a button), molecules (a search form), organisms (a site header), templates (a page layout without final content) and pages (the template with real content).

When a product needs one

Not every product does. NN/g’s guidance points to a few conditions:

You have many screens or several products, and you will keep building them for years.
You have the time, budget and people to maintain it. A design system is an ongoing effort, not a one-off project.
You are not building a short-lived prototype or proof of concept. The payoff comes from reuse, so something likely to be thrown away won’t earn it back.

NN/g also suggests checking first whether an existing open-source system meets your needs. Heavy customisation raises the cost, and a fully custom system may only pay off over the long run.

How to build one, step by step

1. Audit the interface. Brad Frost calls this an interface inventory: take screenshots of one example of every distinct element, then group them into categories such as navigation, forms, buttons, icons and messaging. As Frost puts it, having 37 unique button styles “probably isn’t a good idea.”

2. Define tokens. Start with colour, typography and spacing. Name tokens by purpose, not by value: color.text tells a developer where to use it, while blue-500 does not. Keep them in one source that feeds both the design tool and the code.

3. Build core components. Begin with the elements every screen uses: buttons, text fields, checkboxes, menus, dialogs. Give each one its full set of states, such as default, focus, disabled and error, and use the same names in design files and code.

4. Document. For each component, say when to use it, when not to, and what it needs to stay accessible. A component without guidance gets used in ways nobody intended.

5. Govern and version. Decide how new components get in. The GOV.UK Design System is a good model: a proposal must show it is useful to many teams and doesn’t duplicate anything, and before publication it must be tested with users, including people with disabilities, and across browsers, devices and assistive technologies. Then release changes with version numbers. Semantic Versioning raises the major number for changes that break compatibility, the minor number for compatible new features and the patch number for compatible fixes, so teams know which updates are safe to take.

What it measurably gives you

Treat any big number about design systems with care, and ask how it was measured. One controlled study is worth knowing. In 2019 Figma’s data science team gave designers two comparable tasks, one with a design system and one with only older design files. With the design system they completed the task 34% faster. The author, Clancy Slack, notes that the system was relevant and up to date, so this is likely the maximum saving you would see in real work. Several participants also said they felt more confident in their designs.

NN/g adds benefits that are harder to time: visual consistency, a shared vocabulary between teams, easier onboarding and simpler rebrands. The best evidence, though, is your own. Before you start, measure how long a typical screen takes to design and build, and how many one-off components exist. Measure again six months later.

The takeaway

Treat a design system as a product whose users are your designers and developers: it needs an owner, a roadmap and regular releases. Start with the audit, build only what your screens actually use, and measure whether it saves time before you expand it.