Design System: what it is and when not to have one

The magic phrase

Imagine the following scenario: you're working on a new product, or trying to evolve something that already exists, and you realize that consistency and scalability would make a difference. You want a cohesive design language. You want components that let you build the product block by block, without reinventing everything on every screen.

At some point someone says: "we need to build a design system."

But I turn the question around: do you really?

Before I sound like a champion of disorganization, let me explain. There are contexts in which you really do need a Design System. In many others, a good component library or a UI kit already solves the problem.

If reading this made you think "what, exactly, is the difference?", this text is for you.

If you already know the difference, this text can still help you reflect.

Blocks, layers, and the inevitable confusion

Thinking in terms of blocks, a style guide defines the color palette, typography, spacing, grid, icons, and brand usage. It organizes the product's visual vocabulary.

A UI kit uses that vocabulary to assemble components: labels, buttons, inputs, dropdowns, cards, modals.

This is where the first real friction begins. The UI kit usually lives in Figma. The component library, on the other hand, lives in the code. When these two universes don't talk to each other properly, a mismatch emerges. Figma points in one direction, the code goes in another, and consistency becomes a negotiation with every delivery.

The design system comes into play when you decide to treat all of this as something bigger.

When it becomes a real system

Unlike the first two, a Design System is treated as a product. Hence the classic definition by Nathan Curtis: a product that serves other products.

Product implies responsibility, evolution, and someone taking care of it.

At a high level, a design system brings together appearance rules, behavior rules, documented principles, a maintenance process, and an implementation in code.

The difference starts to show up in the details. Consistency doesn't live in aesthetics alone. A button carries decisions that no one wants to re-debate every week: states, variations, accessibility, loading, disabled, visible focus, keyboard navigation.

When these decisions are consolidated and accessible to the whole team, the pace changes. Repeated discussions diminish. The interface stops depending on the memory of whoever attended the last meeting. The product gains continuity.

When this isn't clear, every screen becomes interpretation. And accumulated interpretations, sooner or later, lead to divergence.

This may sound too grand. And it really is. But it doesn't have to be born fully formed.

The process, at this stage, can be simple: defining how new components get in, who reviews variations, how changes get published without causing a domino effect. There are products of all sizes. With design systems it's no different.

The cost almost no one highlights

But there's a cost.

A design system requires maintenance. It requires alignment between design and engineering. You need someone looking at the whole picture and, at certain moments, saying "no."

Without that care, it starts to lose strength. It turns into a pretty catalog that few people use. Or a place where everything goes in and nothing comes out. Little by little, using the system starts to feel more laborious than working around it. When that happens, the problem is rarely in the isolated component. It's usually in the process, the scope, the lack of curation.

A well-maintained design system brings predictability. An abandoned design system creates a sense of organization that doesn't hold up.

When it makes sense to take that step

When should you use a design system and when is a UI library already enough?

The context decides.

Long-running projects, multiple teams, different products or modules talking to each other: in these scenarios, a design system usually pays for itself. Especially when inconsistency has already turned into rework. When two squads build similar solutions to the same problem. When changing a simple pattern requires combing through the code looking for slightly different versions of the same component.

Here, scalability isn't about growing indefinitely, but rather about reducing the cost of new screens. It's about making things like onboarding easier and being able to change something without feeling like you're pulling a loose thread.

At these moments, the design system stops being a structural whim. It starts to protect time.

If you're in doubt, I like a simple and very practical test. First, do a quick inventory of what already exists today: how many versions of buttons, inputs, and cards does the product really have? Then choose a single "champion" component and treat it seriously, all the way through: tokens, states, accessibility, documentation, and implementation in code. Finally, agree on a minimum of governance, even if informal: who approves variations and how changes get published. That alone already reveals whether you're dealing with organization or whether you're entering system territory.

When a library is enough

Now, another scenario: maybe you're on a quick freelance job, on a small product, with a lean team, or on a project with little reuse and a lot of urgency. In these cases, a good style guide, an organized UI kit, and a lean library deliver enough consistency. Creating a formal structure can add complexity that the project doesn't yet need to carry. Not every context calls for a formal system.

The question that matters

Having a design system changes the way the team works. It provides a common foundation and makes decisions more predictable.

When the priority is to align the visuals and gain consistency quickly, a well-maintained style guide, an organized UI kit, and a lean library already deliver a lot. You establish a standard without creating a large structure to maintain.

Over time, if the product grows, more people join, and the patterns start to spread, the design system becomes worth the effort. It helps maintain continuity, reinforces reuse, and makes changes smoother, because there's a clear place to consolidate decisions.

In the end, a design system shows up when the team is tired of solving the same thing in different ways. If that isn't happening yet, organization already takes you a long way. If it is, maybe it's time to take the next step.