Design System

What is a design system, and why build one?

A design system gathers the decisions that make up a digital product's or website's interface into a single source, used under the same names in both the design files and the code. Colours, type scale, spacing, components and how those components behave all belong to that source.

A design system is not just a Figma file. The file is only its visible face; the real value is that the rules are written down and everyone looks at the same ones. A designer joining the team or an outside agency can read the system and start using the brand's digital language correctly in short order.

The most tangible gain is that the same decision stops being made over and over. A button's corner radius, a form field's error state or the gap between cards is settled once, and every page after that is spent producing rather than debating.

You can usually tell a design system is needed from signs like these:

• The same component exists in several different versions across the site or product
• Designers and developers ask the same questions again for every new page
• Several teams or agencies produce digital work for the same brand
• A small colour or type change turns into weeks of fixes

What is a design token?

A design token is the smallest named unit of a design decision. Instead of defining a colour as a raw value like “#1F4FFF”, you give it a meaningful name like “accent-colour”. The design tool and the code both use that name, so when the value changes everything updates together.

Tokens are usually built in layers. Thanks to that layering, adding a dark theme or refreshing a brand colour means changing the mappings in one layer instead of fixing hundreds of screens one by one.

The basic naming rule is to describe purpose, not value. A token called “blue-button” starts telling a lie the day the brand colour turns green; “primary-action” stays true either way. Tokens live under the same name as variables in the design tool and as CSS custom properties or a similar structure in code.

• Base tokens: every colour in the palette, type sizes and spacing steps (e.g. blue-600, space-4)
• Semantic tokens: names that say what a value is for (e.g. accent-colour, text-secondary)
• Component tokens: decisions specific to one component (e.g. button-background, card-padding)

How is a component library built?

A component library is built from small to large. Basic elements such as buttons, text fields, tags and icons come first, followed by composite components made from them: cards, form rows, menus and modals. At the top sit templates, where those components are arranged into page layouts.

Usage frequency decides which components come first. Buttons, form fields and heading styles that appear on every screen lead the way; rarely used specialist components are added as the need arises. That way the system is in real use from its first weeks.

Drawing a component's default state is not enough. Each component in the library should have its own page covering:

• Variants: options such as primary, secondary or text button, and when to use each
• States: default, hover, focus, disabled, error and loading
• Content rules: maximum text length, use with icons
• Accessibility notes: contrast, keyboard behaviour, screen reader label
• Code counterpart: component name and properties

Design system versus brand guidelines

Brand guidelines describe how a brand looks and speaks: logo usage, colour palette, typography, photography and tone of voice. A design system describes how that identity works inside a digital interface, and it maps one to one onto code.

Neither replaces the other; the identity is the system's source. The guideline's main colour becomes a token in the system, and the guideline's typeface becomes a heading and body scale. Brands with a strong identity but no digital system tend to see their website, app and campaign pages drift apart over time.

In practice the difference also shows in who uses each. Guidelines are opened mostly by marketing teams, printers and agencies; the design system is used daily by product designers and developers. So a rule in the system has to be far more detailed than one in the guidelines: not just what the colour is, but which shade is used in which state.

How does a design system stay current?

Design systems usually break down not because they were badly designed but because nobody owns them. A team builds a one-off component for an urgent need, it never makes its way back into the library, and a few months later there are three parts doing the same job.

To prevent this, how the system runs is defined from the start, just like how it is built:

• A named owner or small team responsible for the system
• How new components are requested and who approves them
• Release notes: what changed and who it affects
• Regular clean-up of components nobody uses