Things I've learned from building design systems

Everything I’ve learned about design systems — after dozens of attempts to make them simple, alive, and useful.

Every design system starts with enthusiasm — and almost always with an underestimation of what lies ahead. Over the years, I’ve seen systems appear, grow, and disappear. Some collapsed under their own weight, others stayed alive and helped teams work better.

With time, I realized: a design system is not a tool, but a process — one that goes far beyond components and color sets.

Here are ten things I’ve learned from building them again and again.

1. The hardest part is not design — it’s alignment

Agreeing how to work is harder than agreeing how something should look. Often, a designer builds a system alone — isolated from development. And when the design is ready, the team starts trying to “align” it with code. That’s when it becomes clear the system doesn’t actually work.

A design system must be tested from day one — not at the end, but throughout the process. Every decision — colors, sizes, states — should be verified in code, in a real interface. It’s how you involve the team and connect design decisions with reality.

A simple example: in Figma, a hover color might look perfect. In a browser, it may be barely visible. Fixing this later means reworking the entire palette, shadows, and contrasts. One small detail can turn into hours of rework.

Alignment isn’t the result of meetings — it’s the result of collaboration. A system becomes alive only when designers, developers, and product people solve problems together in one continuous cycle.

Today it’s Figma, tomorrow it will be something else. Not long ago, Sketch was the standard. Before that, it was Photoshop. Every time, it felt like the perfect tool for building systems — until a few years later, everything changed again.

Tools come and go, but principles stay. Architecture, naming, the structure of tokens — these are the true core of a design system. They define how it’s built, how it can evolve, and how it can be transferred. Components and visual details are just the surface form of this core.

A good system lives independently of the tool that created it. If you switch platforms tomorrow, it shouldn’t fall apart. Whatever can be moved is the real system. The rest is only a shell.

3. Good naming saves months

Clear names create shared understanding. Confusing ones create meetings. A system’s language isn’t just labels — it’s its model of thinking. It shows how the team sees the product and how it makes decisions.

Good names explain purpose, not structure. Naming a style “text-button” describes its role, not its size. Naming a color “fg-accent” defines its function, not its hue. This creates a language everyone in the team can understand.

But naming must also grow with the project. It needs to be extensible. If your color system is built around rigid terms like “weak,” “base,” and “strong,” then the moment you need an intermediate tone, you’ll hit a wall — there’s simply nowhere to put it.

Good naming anticipates growth. It creates a structure where new levels, shades, and states can appear without breaking what already exists. That’s what makes a system resilient and long-lived.

4. The best systems start small

You don’t need hundreds of components or a dedicated team. Start with a button, a palette, and a few typography rules. Real systems grow from use, not from plans.

A common mistake is to build a system first and only then start designing with it. This usually leads to dozens of unnecessary components and states created for cases that never happen. The system looks large, but feels heavy and slow.

A system should indeed be built “for the future,” but not by trying to predict every scenario. It’s not about quantity — it’s about architecture. About the principles for creating components and the methods that make them easy to extend.

If you’ve created a single button and documented the principles behind its proportions — how text, padding, and size relate — you’ll easily create more variants later. You won’t reinvent it; you’ll just apply your own rules.

A good system isn’t a library of ready-made parts. It’s a set of decisions and relationships from which everything else can grow.

5. Document less, explain better

People don’t read endless walls of text. They need short, clear explanations and visual examples. Good documentation doesn’t say what it is — it answers why it exists.

Documentation is the second most important thing after naming. The way it’s written determines whether the system will actually work. Even perfect components are useless if no one can find out how or when to use them.

People don’t need formal descriptions wrapped in paragraphs. They need to see how a component behaves, where it fits, and where it doesn’t. One precise example is worth ten paragraphs.

Documentation should be written during the system’s creation, not after. It should evolve together with the project. Sometimes, it’s even worth writing things down before building them — to clarify your intent and direction.

Good documentation doesn’t just describe — it helps you think. It makes the system understandable not only to those who built it, but to anyone who joins later.

6. Simplicity is the hardest decision

Removing the unnecessary is harder than adding more. But simplicity makes a system clear and reliable. In design systems, it’s not an aesthetic choice — it’s a way to make solutions last.

A design system is about finding solutions that not only look good, but also work well and endure. A fancy button with gradients and effects may impress now but will become a burden later: harder to maintain, harder to update, harder to scale. A simple button will live longer — in both code and interface.

The same applies to variants. Over time, different styles accumulate in different places — a new button for every background or context. A design system helps reveal and reduce that entropy, keeping only a few predictable, consistent options.

The key is to distinguish simplicity from artificial limitations. One heading style isn’t simplicity — it’s lack of structure. Experience helps to know where flexibility is needed. Instead of twenty text sizes, define a modular scale and relationships between size, line-height, and spacing. That’s how you keep flexibility without losing order.

True simplicity looks light but allows growth. Minimal on the outside, adaptable inside.

7. Build in a margin of strength

Simplicity shouldn’t mean poverty. A strong system needs flexibility — a margin of shades, sizes, and styles. The wider the range, the easier it is to adapt the system to reality.

In practice, you’ll almost always need more than you expected. You start with three shades of gray — and soon realize you need fifteen. It’s better to create a full scale from the start — 15 or even 21 tones — even if you use only a few. Unused colors don’t hurt; added later, they break the structure.

The same goes for container widths. At first, one size seems enough. Then you discover you need a narrower one for a blog, a smaller one for forms, and a wider one for a promo page. If you plan naming and range early, adding new sizes later will be easy. It’s just a text list — but in such details, real system thinking shows.

The point is to distinguish a meaningful margin from meaningless excess. A hundred badge styles is noise. A scale that can expand without redesigning the core — that’s strength. A simple structure, clear principles, and a flexible range — that’s the balance that makes a system resilient.

8. Narrow is better than universal

Every project needs its own logic, tone, and rhythm. Trying to make a universal system leads to compromise: components lose identity, structure becomes heavy, and solutions turn generic.

Universal systems make sense only for learning — as templates, demonstrations of principles, or collections of references. Real projects need focused systems. A news site is not a dashboard; a magazine is not a control panel. If you try to serve both with one system, both will suffer — visually, functionally, and commercially.

A practical approach is to keep reusable building blocks at hand — not ready-made components, but collections of ideas: buttons, forms, cards, layouts. Copy what fits into your project and adapt it. This saves time while preserving individuality.

System thinking should live in the approach, not in the form. It’s better to have many small, specific systems than one universal one that fits nothing.

9. Build patterns as examples of real solutions

Patterns are the best way to test a system in action. They show how elements work together — not in isolation — and turn the system into a living tool.

By patterns, I mean real interface situations: a login form, a shopping cart, a product card, a registration flow, an error screen, a profile page. These assemblies show how the system behaves in real contexts and across states.

Patterns give the team a shared picture. Designers see how visuals come together, developers see structure and dependencies, and managers see business logic. It becomes a common ground for clear discussion.

Patterns play a double role: they’re both documentation and testing. They reveal weak points — where consistency breaks, where flexibility is missing, where structure starts to crack.

Regularly expanding and refining patterns isn’t maintenance — it’s evolution. They record how decisions mature and turn the design system into a living reflection of the product itself.

10. A system needs an owner

When no one is responsible, no one cares. A design system lives only when there’s a person or a team who makes decisions, maintains order, and keeps it up to date.

This person holds the system’s architecture in mind. They understand how parts connect, how changes affect other areas, and how to keep the system coherent as the product grows and the code evolves.

The owner isn’t an administrator or the author of every element. They’re the keeper of integrity — someone who reviews, cleans up, simplifies, and lightens the system. Thanks to this role, the system stays lean and relevant instead of becoming cluttered and outdated.

A good system can’t exist on autopilot. It stays alive only as long as someone takes care of it.

The system that stands the test of time

A design system is not a set of rules, but a collection of thoughtful decisions made with care and common sense. It has no final form — it grows, simplifies, and adapts, just like the product itself.

If it has a clear architecture, a shared language, and someone who maintains it, it will endure any change. Everything else — tools, structure, even people — can evolve, but the essence remains.

In Designing Design Systems, I explore in detail how to build such a system — from structure and principles to team collaboration and long-term growth.