Skip to content

Web & Digital Experience

Design systems: grown from real work, then shared

Most companies with more than one site or app have built the same button, form and date picker several times, each a little different. A design system fixes that, but not by drawing every part in advance. Patterns are built for a real product, proven there, then promoted: checked, named, documented and handed to every other product.
Discuss your productsSee the five parts ↓
product workthe design systemreusedbooking pagebuilt herepromotion checkneeded in 2 more placeskeyboard and screen readerworks at 390 widenamed for what it doesdesign systemtokenscolour.accentspace.2radius.smcomponentsbuttonfieldtime-slot pickernewguidancewhen to usestateskeyboardcustomer portaloffice schedulingsame picker, same behaviour, three places

Five parts, and only one is drawings

  1. 01

    Tokens

    The decisions, as named values

    Colour, spacing, type and corner radius, named once, so a change reaches every product.

  2. 02

    Components

    Built, tested parts

    Buttons, fields, the time-slot picker: code that behaves the same wherever it's used.

  3. 03

    Guidance

    When to use what

    Each part documented with when to use it, its states and how it works by keyboard.

  4. 04

    Contribution

    How new patterns get in

    A pattern built for one product is proposed, checked and promoted, never designed in a vacuum.

  5. 05

    Governance

    Who decides

    A named owner decides what's promoted, changed or retired, and records why.

Reuse, adapt or create

Every new screen asks the same question of each part. The answer is a rule, not a debate.

Reuse

When
an existing part does the job
Example
the portal's “Pay invoice” button is the system's main button
Cost
nothing new to build or test

What gets a pattern promoted

Five checks before a part built for one product becomes everyone's.
Proven needIs it needed in more than one place?two products waiting for it
AccessibleDoes it work by keyboard and screen reader?tested with both
ResponsiveDoes it work from a phone to a desktop?checked at each width
Stable meaningWill its name and job stay the same?named for what it does, not how it looks
Fits the systemDoes it use existing tokens?no one-off colours or spacing

What a design system hands off

In

Product work
patterns proven in use
Brand
colour, type, voice
Requests
from every team
Design system
decide once, reuse

Out

Tokens
named decisions
Components
built and tested
Guidance
when to use what

Worth building when more than one product should look and behave alike

Good fit

  • Two or more sites or apps should look and behave alike.
  • The same part has been built three times, three ways.
  • More than one person designs or builds.

Not the right fit

  • One small site, built once. A few shared styles will do.
  • Nobody will own the system after it's built.

Where this capability is used

Next to design systems

Questions about design systems

Do we need one before we build anything?

No. The best systems grow from real products: build the first one, then promote what proved useful.

Isn't a design system just a component library?

The library is the built parts. The system also holds the decisions (tokens), the guidance, and the way new parts get in and old ones leave.

What tools do you use?

A design tool for the visual decisions and a workbench for the built parts, kept in step. The specific tools are chosen with your team.

Who maintains it?

A named owner on your side, with a simple way to propose changes. We can help until that's settled.