Design Systems: When Your Website Needs One

Key Takeaways

• One shared library, plus the rules for using it. Colours, type, buttons, cards and forms, built once.
• Most small businesses need the lighter version. A single style guide page, not a system.
• The famous examples solve a problem you do not have. Many teams, many products, built in parallel.
• Tokens are named values. Change one, and it changes everywhere it was used.
• Start with what already exists. Write down the decisions your site has already made.

What A Design System Is

A design system is one shared library of reusable pieces, plus the rules for when and how to use them. Build the button once, then use that button everywhere.

The point is not documentation. It is that there stops being a decision to make, because the decision was made once and written down.

That matters most on the small things. Nobody argues about the hero layout twice, but the spacing under a heading gets re-decided on every page by whoever is building it that day.

Multiply that by a hundred pages and you have a website that nobody designed, assembled from a hundred reasonable choices.

A design system is mostly a way of not having the same argument twice. What size is a heading, what does a disabled button look like, how much space goes between sections.

What Is Inside One

Four layers, each one built on the layer below it, and each useful on its own.

• Tokens. Named values. A colour, a spacing step, a type size, each with a name rather than a number scattered through the code.
• Components. Reusable pieces built from those tokens. Buttons, inputs, cards.
• Patterns. How components combine. What a form looks like, how a page header is arranged.
• Rules. When to use which, and what never to do.

Tokens are the part that pays off quietly. Change the value once and it updates everywhere it was used, instead of being hunted down across forty files.

They also make a rebrand survivable. A colour change that would otherwise be a fortnight of find and replace becomes an afternoon, with nothing missed in a corner nobody opens.

In October 2025 the Design Tokens Community Group, a W3C community group, published the first stable version of its design tokens specification. It is a community specification rather than a W3C standard, which matters when somebody tells you tokens are now standardised.

Design System, Style Guide Or Brand Guide

Three terms that get used interchangeably in briefs and in sales calls, and that mean three genuinely different things.

Nielsen Norman Group draws the same distinction between a style guide and a design system: one documents decisions, the other ships working parts.

That is the test on the design system vs style guide question. If a developer can use it, it is a system. If they can only read it, it is a guide.

Both are legitimate. The mistake is paying for one and receiving the other, which happens often enough that the question is worth asking out loud before any work starts.

Why Consistency Matters

Consistency is not an aesthetic preference, whatever it looks like from the outside. It is what makes a site predictable, and a predictable site is easier to use than a surprising one.

There is research on how quickly appearance registers, though it is older than most people quoting it realise. A 2006 study by Lindgaard and colleagues, published in Behaviour and Information Technology, found participants' visual appeal judgements were already consistent after about 50 milliseconds of exposure.

The Stanford Web Credibility Project's 2002 study similarly found visual design mentioned more often than any other factor when people explained how they judged a site's credibility.

Both are worth knowing and both are old. Treat them as evidence that appearance registers quickly, not as a formula for what yours should look like.

The practical version needs no research at all. A visitor who cannot tell whether two pages belong to the same company has been given a reason to check, and checking is friction.

Consistency removes that question before it is asked. That is the entire argument, and it holds whether or not the measurement was taken in milliseconds.

Who Actually Needs One

Four conditions decide it, and meeting two or more makes a real system worth building.

Meeting one is a maybe. Meeting none is a clear answer that people routinely talk themselves out of.

• Several products or websites. Not several pages.
• More than one person building. Especially in parallel.
• Many templates. Enough that nobody remembers them all.
• Frequent new pages. Shipping constantly, not once a year.

A five page site built by one designer meets none of these. Building a ui design system for it is a way of spending a fortnight to avoid an afternoon.

The honest answer for most small businesses is that the work belongs in the site itself. Decide the spacing properly once in the stylesheet, and the consistency is enforced by the code rather than by a document.

Why The Famous Examples Do Not Apply

Every article on this topic names the same handful of examples from very large companies. It is the least useful thing such an article could do.

Looking at them is still worthwhile, provided you look at why they exist rather than at how they look.

Those systems exist because hundreds of people build hundreds of surfaces and need to not contradict each other. The system is cheaper than the coordination it replaces.

At small scale that trade reverses completely. The coordination cost is a conversation, and the system is a month of work plus permanent maintenance afterwards.

A system is only cheaper than the coordination it replaces. With one or two people, there is almost no coordination to replace.

So read the famous examples as evidence about scale, not as a standard to live up to.

Starting Small

A one page style guide gives a small website most of the benefit for a fraction of the effort, and it can be written in an afternoon from the site you already have.

Three things, in this order, because each one settles an argument the next one depends on.

1. Write down the colours

Name every colour the site actually uses and what each one is for. Not a palette of twelve. The four or five that appear, with a job each.

This is usually the first moment somebody notices there are three slightly different greys in use, none of them deliberate.

Pick one of them, delete the others, and give each surviving colour a plain name. Text, background, accent, border, warning.

2. Name the type sizes

Write down the sizes in use and give each one a name and a purpose. Heading, subheading, body, small print.

Four or five sizes is plenty for a small site. Anything more and nobody can tell which one a given piece of text is meant to be.

Write the names down beside a sample of each. A list of pixel values with no examples is the kind of document that gets opened once.

3. Settle the buttons

Decide what a primary button looks like, what a secondary one looks like, and whether a third exists at all.

Two is almost always enough. A third button style exists mostly because somebody needed a visual difference once and never removed it.

Write down the states as well. What a button looks like when hovered, pressed, loading and disabled is exactly the detail that gets invented differently on every new page.

Common Mistakes

Three failures are worth knowing about, and two of them come from enthusiasm rather than from neglect.

Building one too early. A system for a site that does not exist yet documents guesses rather than decisions.

Documenting what nobody uses. Thirty components, four of them in production. The other twenty six are a maintenance bill nobody agreed to pay.

Letting it drift from the code. The moment the documented button and the real button differ, people stop trusting the documentation and go back to copying whatever is nearby.

Drift is the one that kills systems which were working. Keeping a document in step with a codebase is a job, and somebody has to be doing it on purpose.

FAQs

What is a design system in simple terms?

It is one shared library of reusable pieces, plus the rules for using them. Colours, type, buttons, cards and forms are built once and then reused everywhere, so nobody has to decide what a button should look like ever again.

What is the difference between a design system and a style guide?

A style guide documents decisions that somebody can read. The other ships working components that somebody can actually use. If a developer can only read it, it is a guide. If they can build with it, it is a system.

What is the difference between a design system and brand guidelines?

Brand guidelines cover the widest ground: logo, voice, colours, print and advertising, across everything the business puts its name on. The other is narrower and more technical, covering the working pieces a website or product gets assembled from day to day.

What are design tokens?

Design tokens are named values. Instead of a colour appearing as a raw code in forty different files, it has a single name that is used everywhere. Change the value once and everything using that name updates with it, consistently and immediately.

Does a small business need a design system?

Usually not. A one page style guide covering colours, type sizes, buttons and spacing gives a small website most of the benefit for a fraction of the work. A full system earns its keep only when several people build several products in parallel.

Conclusion

A design system is worth building when coordination between people costs more than maintaining the system would.

Below that line, write a one page style guide: the colours, the type sizes, the buttons and the spacing, named and settled.

See how we approach web design, or get in touch and we will set up whichever of the two actually fits.