What a design system is, and what it is made of

A design system is a project’s shared language: principles, tokens, components, rules for using them, code, documentation and a process for changes.

From a set of rules to a system

Every project sooner or later meets the same thing: on the second page the button came out a slightly different blue, on the third the spacing is a little smaller, and on the fifth someone invented a new card. Each decision on its own is sensible, but together they drift apart. The visitor doesn’t put it into words, but feels it: the site is “put together from different places”.

The cure is called a design system. It’s the shared language of a project: principles, values (colors, sizes), ready-made parts (buttons, fields), rules for using them, code that reproduces them, and an agreement on how all of it changes. Nielsen Norman Group describe it as a set of standards for managing design at scale, with a shared language at its center (their article is linked in the sources).

Three terms get mixed up, so let’s separate them.

• A style guide. A document: “our blue is this one, the font is that one”. It describes, but reproduces nothing.
• A component library. Ready-made parts as code or as a Figma file. They reproduce, but don’t explain when to take which.
• A design system. All of it together: the principles, the values, the parts, the documentation, the process for changes, and the people responsible.

Check yourself: how does a system differ from a style guide?

A style guide only describes. A system also contains code that people use, shared names for values, and the people who maintain it.

Nine layers

A system has no single mandatory “shape”, but the big public systems have the same layers. On the diagram, choose the size of the project and see how many layers you need. Open any layer: it says what question it answers and how it’s arranged in real systems.

One person, one siteA team, a few pagesA company, several products

Principles neededFoundations neededTokens neededComponents optionalPatterns can skipWords optionalCode can skipDocumentation optionalGovernance can skip

Principles. It answers the question: What do we believe in when we settle a dispute?

What is inside. Three to five short rules, for example “clarity first, beauty second”.

Who is responsible. Whoever is responsible for the product and the design.

In real systems. GOV.UK’s design system follows the open Government Design Principles.

In a small project. Three rules on your project’s passport page.

Here are the same layers in words.

1. Principles. Three to five short rules for disputed cases: “clarity first, beauty second”. GOV.UK’s system stands on the open Government Design Principles.
2. Foundations. Color, typography, spacing, grid, icons, motion. You have already made three of them in the earlier lessons.
3. Tokens. Named values everything is built from: color.text.primary, space.200. Two lessons below are given to them.
4. Components. A button, a field, a card, a menu: each has variants and states (default, hover, focus, disabled, error).
5. Patterns. Solutions to common tasks made of several components: a sign-in form, search, a confirmation. GOV.UK keeps them strictly apart: “components” in one place, “patterns” in another.
6. Words. Tone of voice, rules for buttons, error messages, names. Words are part of the interface, and Carbon gives them a section of their own among the foundations.
7. Code. A library you can install and use: a package, examples, tests.
8. Documentation. When and how to take each part, when not to, “do” and “don’t” examples, notes on accessibility.
9. Governance. Who is responsible, how to propose a change, how versions change, how the outdated is retired. This is the most underrated layer: a system with no owner turns into a dump within a year.

Why bother, and what it costs

A system pays off like this:

• One look and one behavior. The visitor gets used to it once.
• Speed. A new page is assembled from ready parts, not drawn anew.
• Quality and accessibility “out of the box”. Contrast, focus and sizes are fixed in one place, and so they are fixed everywhere.
• Scale. Dozens of people work on a product, and the system holds them together.

It has a cost too: time to build it, time to maintain it, and the risk of “locking” the design into old decisions. So the size of a system is fitted to the project. A one-page site needs a light one: principles, tokens, five or six components and a reference. To ignore a system entirely is expensive too: you’ll create one anyway, only by accident and sloppily.

One source of truth

A designer draws in Figma and a developer writes code, and two versions of the “truth” easily appear: a mockup with some values, a product with others. So mature systems choose one source from which the rest is taken. Most often it’s a tokens file and the code of the components: from them the Figma variables, the CSS and the documentation are all built. You’ll see how this is done in the lessons on tokens and on handing a design over to code.

Check yourself: does a one-page site need a system?

A light one: principles, tokens, five or six components and a short reference. Patterns and governance can be skipped.

Practice

Write the passport of your project’s design system. It’s one small table, but filling it in honestly isn’t as easy as it seems: you’ll have to answer what your principles are, and what you’ll do and what you won’t. The passport will be useful in the last lesson of the part, when you put your own small system together.

What was wrong with 2014

In 2014 a “design system” was often an album in a PDF: beautiful, but not connected to code. Within half a year the code drifted from the album, and nobody opened the album any more. The lesson of that era: a system is alive if it has code and an owner, and dead if it’s only a document.