Refract Group2026
Glossary
Design system
A design system is the shared set of parts a product is built from and the rules for using them: named values for colour, type and spacing, components with their states, the patterns they combine into, and when each one applies.
- RulesWhere each part belongs, and why
- PatternsRecord opens in a panel beside the list
- ComponentsButtons, inputs, tables, with states
- Design tokensNamed values for colour, type, spacing
Design system in detail
- Also called
- Design language system, Product design system, UI system
- Topic
- Product
- Updated
What it is
The parts sit in layers. At the base are design tokens, the named values for colour, type, spacing and grids. Components are built from those values: buttons, inputs, tables and panels, each drawn with its loading, empty, disabled and error states. Patterns are the ways components combine for a job the product repeats, such as opening a record in a side panel while the list stays in view. The rules say where each part belongs and what it does when the data is missing or too long.
A working system lives in two places that have to match: a library in the design tool for designers, and coded components for engineers. Nielsen Norman Group counts the people who maintain it as part of the system: someone has to decide which version of a part stays when two exist, and keep the file and the code in step.
Why it matters
Products that grow a feature at a time collect small differences. A button saves and closes the panel on one page and saves and stays open on the next. A filter reads one way in the table and another in the report. Together they make people relearn the product as they move through it. A design system gives each decision one home. Engineers build a new screen from parts whose states are already worked out, and a fix to a component reaches every screen that uses it.
How we do it
We start by auditing the interface you have, writing down every type style, colour, spacing value, icon and component in use. We mark what is duplicated, settle which version of each part stays and agree the list with your designers and engineers, including what each component does: whether saving closes the panel, where validation appears, which action can be undone.
Each part is then drawn in Figma on your product’s own content, with its loading, empty and error states from the start. We build the system in code, in the stack your engineers already use, and check each one in staging. You get the Figma library, the coded components and a rule for each part, in your own accounts. It is scoped as product design, from $10,000 a month.
An example
Say an analytics product has rebranded with a warm, bright palette, and the first screens drawn with it put the new colours everywhere. They compete with the numbers people read all day. The system settles it with one rule. Warm neutrals from the palette take the surfaces, and the accent colour is kept for state, action and selection alone. Dense tables stay quiet, and the brand shows in navigation, empty states and success moments, where nobody is reading a figure.
Common mistakes
- Building the library and calling it the system. Two teams can use the same button and still ship screens that behave differently, because nobody wrote down when it saves, closes or warns.
- Drawing parts on tidy sample data. A table designed with three short rows hides the long names, missing values and two hundred records it will hold in staging.
- Leaving the states for later. A component handed over without its loading, empty and error states gets those states made up at build time, differently on each screen.
Design system vs component library
A component library is the built parts, and a design system is those parts plus the values they share, the patterns they combine into and the rule for when each one applies.
| Design system | Component library | |
|---|---|---|
| Holds | Tokens, components, patterns and rules | Built components and their options |
| Answers | When to use a part, and why | How to use a part in code |
| Lives in | The design tool and the codebase | The codebase |
| On its own | Rules with nothing to build from | Same button, different behaviour |
Questions
What people ask about design system.
A style guide records how the brand looks: colours, type, logo use and often tone. A design system includes those values and adds a product’s working parts: components with their states, the patterns they make and the rules for using them. Nielsen Norman Group treats the style guide as one part of a design system.
A startup needs a design system once the same patterns turn up across the product and more than one person is building screens. The usual sign is one control behaving two ways on two pages. Before that, a handful of screens that change weekly is better served by consistent screens and a short list of shared values.
A design system should be in both, and the two should match. Designers work from a library in Figma or a similar tool, and engineers build from coded components. A system that exists only in the design file gets rebuilt by each engineer who reads it, and one that exists only in code gives designers nothing to draw with.
Where this shows up in our work
Related terms
Working on this now?
Tell us what you’re building and where it’s stuck. We reply within 12 hours.
Most teams start with a call, then a sprint or an audit.
The people you’d work with, from the first call to launch