UI/UX design

Design system: what it consists of and how to check that it is used

Tokens, components, composition — and commands in the terminal, which show whether the system is really used, or if it exists only in mockups.

The design system lives in production HTML. Not in Figma, not in the component repository. It can be seen in how many different shades of gray are actually given to the browser, how many variants of the "Buy" button there are on the site, and whether the focus on the keyboard behaves the same in the checkout and in the feedback form. Everything else is intentions.

Below is what the system is made of and how to see with your own eyes whether it is being used or not.

What breaks when there is no system

The symptoms are recognisable. 40 shades of gray live in the compiled CSS, because each new screen brought its own. The Submit button has three different heights on three pages. The developer, having received the layout of a new section, spends half a day to find out which indent is "correct" here, and in the end takes the one that stood in the neighboring component.

Another cost is the inability to quickly change something globally. The brand changes the main color: in the system, this is the modification of one token. Without a system - a search in the entire repository, a week of edits and almost guaranteed a forgotten hover somewhere in the footer of the old landing page.

Three levels: tokens, components, composition

Level 1: Tokens

Tokens are atomic values ​​that everything else references. There should not be any "magic" number in the component.

:root {
  /* Colors */
  --color-primary-50: #f0fdf4;
  --color-primary-500: #22c55e;
  --color-primary-900: #14532d;

/* Typography */
  --font-family-sans: 'Inter', system-ui, sans-serif;
  --font-size-sm: 0.875rem;
  --font-size-base: 1rem;
  --font-size-lg: 1.125rem;

/* Indents */
  --spacing-1: 0.25rem;
  --spacing-2: 0.5rem;
  --spacing-4: 1rem;
  --spacing-8: 2rem;

/* Shadows */
  --shadow-sm: 0 1px 2px rgba(0, 0, 0, 0.05);
  --shadow-md: 0 4px 6px rgba(0, 0, 0, 0.1);
}

The rule that saves the most arguments: you can't write color directly in a component. Variable only. Not having the right nuance is a reason to talk about a token rather than adding another hardcode.

Level 2: Basic components

// Button.tsx
interface ButtonProps {
  variant: 'primary' | 'secondary' | 'ghost'
  size: 'sm' | 'md' | 'lg'
  children: React.ReactNode
  isLoading?: boolean
}

Tags

FigmaUXTailwind CSSReact

Did you like the article?

Your opinion helps us create better content

Share with friends

Found something useful?

Help others learn about it - share the article on social networks

Thank you for helping us grow

Founder of LIONEX

Vladyslav Chystiakov

Writes about what he builds himself: online stores on OpenCart, applications on Next.js, integrations and site speed. The articles carry measurements and checks a reader can repeat on their own project, not general advice. Commercial development since 2015.

Questions

Frequently asked questions

Answers to common questions on the topic

Why would a small project need a design system?

So that ten buttons do not turn into ten different buttons. A system is needed not because of project size but because of the number of hands and the passage of time: as soon as more than one person works on the interface, or changes continue beyond a few months, consistency starts falling apart on its own. On a small project the system is small too — tokens and a dozen components, not a multi-volume manual.

Where do I start if the interface is already built?

Not with components but with an inventory: collect every colour, text size and spacing that actually occurs in the code. The list usually turns out longer than expected, and it is what shows the real scale. Then reduce it to tokens and rewrite components gradually, rather than redoing everything in one go.

How do I check that the system is actually being used?

The simplest check is a search through the code: how many places use a token and how many still hard-code the value. If dozens of hard-coded colours remain after the rollout, the system exists on paper only. The second sign is whether new components keep appearing outside it.

When will the first noticeable result appear?

This is not a project with a completion date but a way of working. The first genuinely useful part — tokens and base components — arrives quickly: after them new screens are assembled noticeably faster. Then the system grows along with the interface and has no separate "finish". We give the term for a specific scope after a review, in working days, and fix it in the contract.

What does a design system not give you?

It does not make the product usable and does not replace decisions about what to show a person. A system removes inconsistency and speeds up assembling screens, but a bad flow built from flawless components remains a bad flow. It is a tool for consistency, not a substitute for design thinking.

Get the best articles by email

Subscribe to our newsletter and receive useful tips, insights and news about web development, marketing and business.

We respect your privacy. You can unsubscribe at any time.