A design system is a shared set of standards, reusable components and documentation that lets a team build consistent interfaces at scale. Tokens hold the visual decisions, components apply them, and written guidance explains how everything fits together.
It is one of the most practical ways to put ui design principles into daily work, because the principles are encoded in parts that people can reuse instead of rediscovering them on every project.
What a design system is made of
The Nielsen Norman Group defines a design system as a complete set of standards intended to manage design at scale, using reusable components and patterns. The same article splits the idea into the repository, which holds the assets, and the people who manage it. The repository often contains a style guide, a component library and a pattern library.
Each layer answers a different question:
- Style guide: what do the brand and the interface look and sound like? It covers colour, typography, imagery, tone of voice and visual and interaction standards.
- Component library: which interface elements exist, and how are they built? Entries typically carry a name, a description, adjustable attributes, states and code snippets.
- Pattern library: how are elements combined into common solutions? The Nielsen Norman Group says pattern libraries feature collections of UI-element groupings or layouts, such as page headers and form arrangements.
Another layer, often neglected, is the team. Without people who maintain and approve changes, a system drifts out of date. The same source states plainly that creating and maintaining a design system is a time-intensive activity which requires a dedicated team.
Design tokens: the values underneath
Tokens are the smallest unit of a system. Wikipedia describes a design token as a named variable that stores a specific design attribute, such as a colour, typography setting, spacing value or other design decision. Instead of typing a raw colour code into every component, designers and developers refer to a name, and the name points to the value.
The Design Tokens Community Group gives a technical definition: a token is information associated with a human readable name, at minimum a name/value pair. The group also explains that tokens are a methodology for expressing design decisions in a platform-agnostic way so that they can be shared across different disciplines, tools and technologies. Its specification is still a draft, so tool support and file formats continue to evolve.
Tokens are usually organised in tiers:
- Primitive tokens record raw options, such as a palette of hues or a scale of spacing steps.
- Semantic tokens give those options a purpose, such as a text colour, a surface colour or an error colour.
- Component tokens bind semantic values to a specific part, such as a button’s background.
This layering makes large changes cheap. Switching a theme, adding a dark mode or rebranding a product means changing the mapping in one place rather than editing every screen by hand.
The U.S. Web Design System shows a restrained approach. It explains that its tokens are a limited set of discrete options drawn from a much wider range of possible values, which speeds up design work and keeps communication between designers and developers simple.
Components and their documentation
Components are where tokens become something people can use. A well-documented component entry tells a reader what it is, when to choose it, how it can be customised and how it behaves. The Nielsen Norman Group lists the typical fields: a unique name to avoid miscommunication, a description, attributes that can be adjusted, states that show recommended defaults and the subsequent changes in appearance, and code snippets.
Good documentation goes beyond appearance. Strong entries also cover:
- Usage guidance: when to use the component and when a different one is the better fit.
- Content rules: how labels, error messages and empty states should be written.
- Accessibility notes: keyboard behaviour, focus handling, and how assistive technology announces the component.
- Do and don’t examples: short comparisons that show common mistakes.
Icons are a good example of an asset family that benefits from system thinking. A shared grid, stroke weight and corner treatment keep a set looking related, a topic covered in the guide to icon design.
Many teams also publish their documentation in a dedicated site so that designers, developers, writers and product managers read the same source. Having one agreed place to look is much of the benefit: it replaces opinion with an agreed reference.
Why teams adopt a system, and what it costs
The Nielsen Norman Group sets out the main benefits. A system lets work be replicated quickly and at scale, frees designers to tackle more complex problems, and creates a unified language within and between cross-functional teams. It also provides a single source of components, patterns, and styles, which keeps experiences visually cohesive across products and channels.
The costs are real as well. Upkeep needs ownership, new contributors need training, and there is a perception in some organisations that projects are one-off creations that do not need reusable parts. A system is not finished once released. It evolves as teams give feedback and as products change.
It also helps to be clear about what a system is not. The Nielsen Norman Group cautions that a design system should not be thought of as a portfolio of work, but rather as a functional toolkit or resource for designers and developers to work more quickly. A system that exists to look impressive tends to be neglected by the people it was meant to serve.
Starting small: adopt, adapt or create
There is no need to build everything at once. The Nielsen Norman Group describes approaches to adopt an existing system in its entirety, adapt an existing system to the company’s needs, or create an entirely new one. The more custom the solution is, the more time and money it will take to implement, so many teams start from an open-source system and customise it only where their needs differ.
A sensible sequence for a small team looks like this:
- Audit the current product and list the buttons, inputs, colours and type styles that are actually in use.
- Consolidate duplicates and name the survivors consistently.
- Define foundation tokens for colour, type and spacing.
- Build and document the most-used components first.
- Assign an owner and a lightweight process for proposing changes.
Teams that begin with a collection of ready-made parts will find that a ui kit is a quick way to get components onto a canvas, with the system adding the rules, tokens and ownership that a kit alone lacks.
A prototype or short-lived experiment may not justify the effort. The benefits come from repeated, consistent design work, so the investment pays off best when a product is expected to keep growing.
Frequently asked questions
What is the difference between a design system and a style guide?
A style guide is one part of a design system. It records visual and content standards, while the system as a whole also includes components, patterns, code and the team that maintains them.
Do small teams need a design system?
Not always in full. A small team can start with shared tokens and a handful of documented components, then expand as the product and the number of contributors grow.
What are design tokens used for?
Tokens store design decisions such as colours, type settings and spacing under human-readable names. Components reference the names, so a change to a token updates every place that uses it.
Who should own a design system?
A named team or role that includes design and development skills. Ownership covers reviewing contributions, retiring outdated entries and keeping documentation current.
