Design system

A design system is a structured, documented set of components, visual rules and usage principles, shared between designers and developers to keep a digital product consistent. Typography, colors, spacing, interface components and best practices live together in one place.

The layers of a design system

It is easier to grasp when you cut it from the most abstract layer to the most concrete:

1. Principles. What the product aims to be (simple, accessible, reassuring) and the decision rules that follow.
2. Foundations. Colors, typefaces, spacing and shadows, stored as design tokens: named values usable in both design and code.
3. Components. Buttons, fields, cards and menus, with their states and variants. This is the part that resembles a UI kit.
4. Patterns. Combinations of components that keep coming back: a sign-in form, a filterable table, a page header.
5. Documentation. For each element: when to use it, when to avoid it, how to make it accessible, how to implement it.
6. Governance. Who decides to add or change a component, how a change is proposed, how versions are released.

Many teams organize components along atomic design lines, a method that sorts them by level, from the simplest to the most complex.

What it is for

• Consistency. The same button behaves the same way everywhere, without each team redrawing it.
• Speed. Screens are assembled from existing parts instead of starting from scratch.
• Quality by default. Accessibility (contrast, keyboard focus) is solved once, inside the component, and every screen that uses it benefits.
• A shared language. Designers and developers talk about the same objects with the same names, which narrows the gap between mockup and shipped product.
• Faster onboarding. Newcomers find a reference instead of guessing.

When do you need one?

Not always. For a site of a few pages, a well-named component library is plenty. A design system pays off when several signals pile up:

• several products, sites or teams building interfaces in parallel;
• screens that drift apart over time, with buttons and colors that vary;
• time lost redesigning or recoding the same elements;
• an upcoming redesign you want to evolve without redoing everything.

The opposite trap exists too: building a system too early, before you understand what the product really uses. The sensible path is to start from an inventory of what exists, build a UI kit, then grow it into a system when the needs justify it.

How to start

1. Audit the interface. Screenshot every button, form and card in the live product and group the duplicates.
2. Define the foundations. Pick the color, type and spacing values the product will keep, and store them as variables or tokens.
3. Build the most used components first. Look at usage, not preference.
4. Document them as you go. A short note on when to use each one is enough to begin with.
5. Pilot on one real project before rolling it out. Adjust what the team finds awkward.
6. Name an owner. A system with no owner stops evolving within months.

Public examples worth studying

Several design systems are published online and read like manuals: Google’s Material Design, IBM’s Carbon, Shopify’s Polaris and the U.S. Web Design System (USWDS) for federal websites. They show how to structure documentation, word accessibility rules and present components. They are not models to copy as is: each answers the needs of its own organization.

A design system on Webflow

On Webflow, a design system rests on three building blocks: variables for colors, fonts and spacing, classes named according to a clear convention, and reusable components across the site. Shared libraries now let you distribute them across several sites in a workspace, as we describe in our article on Webflow shared libraries. On the design side, our guide to structuring a design system in Figma shows how to prepare components so development can follow.

Measuring whether it works

A design system can be steered with a few simple indicators:

• the share of screens built with components from the system, as opposed to hand-made elements;
• the time needed to deliver a new page or screen, before and after;
• the number of duplicates spotted (three near-identical buttons, two competing grids);
• the change requests received: too few suggests an ignored system, too many an unsuitable one.

Common pitfalls

• A system nobody adopts. If it is too rigid or poorly documented, teams work around it.
• Components that are too specific. One-off pieces belong in the project, not in the shared system.
• Outdated documentation. It is worse than none, because people trust it.
• Design and code out of sync. The mockup and the live site end up saying two different things.

Mazette.co builds design systems, with a typography guide and a UI kit, as part of its UX/UI and Product design offer.