Without a design system, you do the same thing over and over again
Main chat
A chat for vibe coders: news, guides, live cases, marketplace, and finding executors.
Take any product over a year old and open three different screens. Find the Save button on each. You’ll probably see three slightly different buttons: padding is slightly different, border-radius is slightly different, and the font is a different size. Nobody did that on purpose. The first developer did not find the right component and wrote his own. The second set up the library to make it faster. The third copied from another screen but accidentally changed the style.
It's not a team problem. It's the lack of a system.
What the design system decides – specifically
A design system is not about “making beautiful.” It's about speed and predictability.
Speed. The designer doesn’t draw a button, he takes it from the library. The developer doesn’t write a button; it uses a component. The AI agent doesn’t come up with a button – it addresses the system by name. Every step saves time. Multiply by the number of components and screens, you get weeks.
** Predictability.** The main color of the brand changes – one token changes, everything is updated everywhere. You need a dark theme – Mode switches to Variables. A new developer comes and opens the documentation and sees what to use.
The three parts that provide this are:
- Tokens are named variables for visual values.
color/brand/accentinstead of#E94560.spacing/mdinstead of16px. You change the meaning in one place, change everywhere.
**Components are building blocks with a full set of states. One button with options (Primary, Secondary, Ghost) and states (Default, Hover, Disabled, Loading) are not eight different buttons.
**Documentation rules when to use it. Not only for designers and developers, but also for AI agents who work with the code base.
Three pain points without a system
You answer the same questions over and over again
"Is this 16px or 18?" "Is it the same blue as the hat?" “What should a button do in a disabled state?”
Each question is 15 minutes of lost time. The answer was given a month ago to another developer. But there's no record. We need to explain again.
The average team loses 3-5 hours a week on such questions. This is more than two working months a year, just for what has already been decided before.
Any change is manual work
The product changes the main font. Without a system, it bypasses every screen in Figma and every component in the code. Forty screens, three hours of work, and there are still three places that have been forgotten.
"Let's try a different shade of blue" - without tokens it's not an experiment, it's a half-day project. With tokens, five minutes.
AI generates “something similar but not the same”
In 2026, AI tools will generate screens and components. Without a system context, every prompt is a lottery. AI doesn't know that Button is called Button/Primary, that indentations are multiples of 4px, that Inter is forbidden. It takes the most common patterns from training data — that is, shadcn with Inter by default.
After 20 screens without a system, the product looks like it was made by different teams with different tastes. One team did, though.
Why “just agreeing” doesn’t work
The first reaction to this problem is, “You just have to make rules and watch.” It doesn't work for three reasons.
** New people. ** A new developer is coming. He was told the rules. He remembers a week. Then forgets, because there is no quick answer "how is right here.".
** Deadline pressure. When a task is on fire, do it quickly, not correctly. Detail components, write values directly. Then they forget to fix it. Technical debt accumulates silently.
AI does not know the agreements. No matter how much the team agrees with each other, the AI agent will not take this into account if the rules are not fixed in the contextual files it reads.
The system solves all three: the rules are fixed in tokens and components, not in people’s heads; it is more convenient to do using the system than without it; AI reads DESIGN.md and AGENTS.md.
How to start – without pain and without a big move
The most harmful thing you can do is try to build the perfect system before you start using it. This leads to spending a month on a system that then lies idle.
Working Approach: Minimum-sized system to be used immediately.
Day 1-2: tokens. Figma Variables: colors (primary, surface, text/primary, text/secondary, border, error, success), typography (5 levels - display, heading, subheading, body, caption), indentations (4px-grid: 4, 8, 12, 16, 24, 32, 48). Connect through Tokens Studio to JSON in the repository.
It won't take a week. You can create basic Variables in Figma in 2-3 hours. Tokens Studio is set up in an hour. The result is a working pipeline from Figma to CSS Custom Properties.
Day 3-5: Five basic components. Button, Input, Card, Badge, Modal. Each one is on Auto Layout, with [Тип]/[Вариант]/[Состояние] names, with tokens, with a full set of states. Do not draw everything from scratch – take the existing components that are already in the product, lead to a single standard.
**Day 6-7: documentation. ** One page in Figma or Notion. For each component: when to use what is forbidden, examples of correct and incorrect use. DESIGN.md at the root of the repository: component names, prohibited fonts, tokens. That's what AI reads.
Total: one working week. After that, the team has a working system.
Three seat rule
How not to grow a system into a monster that no one supports: a component is added to the system when found in three different locations of the product. Not before.
It is only used on one screen – a part of that screen, not a component of the system. On two, it may soon become a component. It comes in three different contexts — add to the library.
This prevents the situation of 200 components of which 150 were used once.
What changes a month after launch
The first two weeks are the hardest. The team is not used yet, there is a temptation to do "as before." Important during this period: every PR is tested – “does it use components from the system?”.
After a month, there is a fracture. The team sees what to do on the system faster. You don’t have to make decisions about flowers, they’ve already been made. You don’t have to tell AI what to use – it reads DESIGN.md.
After three months, the system begins to live itself: people add components when they see a repetition, they update the documentation themselves. This is the moment when the system works rather than being maintained through force.
Prompt for auditing before creating the system
Analyze the codebase and find:
1. All unique hex values of colors in CSS and Tailwind.
Sort it by frequency. Top 10 candidates for tokens.
2. All components with "button" or "btn" in the name.
For everyone: padding, font-size, border-radius, background.
Which differ only in one meaning? It's doubles.
3. The most common values of padding and gap. Are they the 4th?
Result: list of the 5 most expensive places where there is no consistency
with specific files and lines.● Tokens created before components – mandatory procedure
Figma Variables synced with code through Tokens Studio
Components: [Type]/[Variant]/[State], all states explicitly
Documentation: when to use what is prohibited, examples
DESIGN.md in a repository with component names and AI bans
● Review Rule: Does PR use components from the system?
