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.

August 1, 2026
2 min read

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

https://lionex.com.ua/blog/design-system-guide

💚 Thank you for helping us grow

Vladyslav Chystiakov

Пише про те, що робить руками: інтернет-магазини на OpenCart, застосунки на Next.js, інтеграції та швидкість сайтів. У статтях — заміри й перевірки, які читач може повторити на своєму проєкті, а не загальні поради. Комерційна розробка з 2015 року.

Frequently asked questions

Answers to common questions on the topic

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.

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.

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.

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.

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.