Most people discover Design Systems through a Figma file. Someone shares a library. “Here are all our components.” They browse through it, nod, and go back to their work. And then, six months later, they’re still having the same arguments about spacing. Still debating whether a button should be outlined or filled. Still building the same header in three different teams.
That Figma file wasn’t a Design System. It was a start. There’s a significant difference.
The definition I keep coming back to: a Design System is the official way in which a company designs and develops its digital products. A set of rules, processes and tools that help make intelligent and coherent decisions.
The most important word in that sentence is not “design.”
Why This Level of Complexity Even Exists
To understand what a Design System actually solves, you need to understand the scale of the problem.
Take a company like Fotocasa, a real estate marketplace I worked with. On the surface: one product. In practice, it’s a constellation. Applications for professionals, for individual sellers, for home hunters. Each of those products lives across a website, a native iOS app, an Android app, and various touchpoints in advertising and social media. And behind all of it, multiple independent teams. One handles search and filtering. Another owns account creation. Another manages everything that happens once you’re logged in.
These teams work autonomously. That’s intentional, it’s how you move quickly. But they’re building parts of the same experience. A user might browse on their phone, create an account on their laptop, and complete a transaction on their tablet. Every hand-off needs to feel like the same product.
Visual consistency in that environment isn’t a nice-to-have. It’s structural. And reusable symbols in a design tool, or shared components in a code library, get you part of the way there. But only part of it.
What Doesn’t Make a Design System
Style Guides and Brand Manuals have existed for decades. Car manufacturers, packaging designers, newspaper editorial teams: all of them have been solving consistency problems at scale long before anyone built a website.
The Lego analogy. The recipe analogy. The atoms-and-molecules analogy. All of them capture something real about how a Design System works. But none of them explain why a Design System is different from what came before.
Here’s the distinction: a Style Guide tells you what things look like. A Design System tells you how decisions get made.
You can have every token exported, every component documented, every pattern catalogued, and still not have a system. I’ve seen it many times. The parts exist. The agreement doesn’t.
Equally, I’ve seen teams with no shared Figma library, no component framework, barely any documentation, who are genuinely operating as a system. They talk to each other. They share a language. When someone says “L spacing”, everyone knows what that means. The system is in the culture, not just the tools.
The Word That Actually Matters
The reason we need Design Systems now, and didn’t always, is that digital product development has become genuinely complex in a way it wasn’t before.
Twenty years ago, I was designing for the web using tools built for posters and advertising. Each page was painted independently. Consistency was a goal, not a requirement. There was no “multi-device reality”. Smartphones didn’t exist. Accessibility wasn’t in the conversation. A designer could change something without a deployment pipeline, without worrying about traffic costs, without understanding how a component would behave across six breakpoints.
That world is gone.
Today, the front-end carries an enormous amount of logic. Components aren’t just visual elements, they’re behaviour, state, data. The same piece of design and code gets reused, modified in real time, adapted to context. A single button might appear on web, iOS, Android, in a third-party payment gateway, in a marketing email. It needs to be consistent, accessible, performant, and easy to maintain.
This isn’t about tools getting better. It’s about the problem getting bigger. Design Systems are not a trend. They are the natural and necessary evolution of how you manage that complexity at scale.
What the System Actually Does
A good Design System is not a collection of assets. It’s a living agreement.
It gives teams the ability to make decisions and know what to do at any given moment. Not just when following the consensus, but also when they need to break from it. That’s why documentation matters more than most people think. Not a gallery of components. A reference you can link to, quote in a conversation, open in a meeting to resolve a disagreement.
“Large spacing means 16px. Here’s the link.” That’s a system working.
It’s also, genuinely, a living thing. Not just in the sense that it evolves over time, updating with trends and absorbing new technology. But in the sense that it corrects wrong decisions after they’ve been made. It’s designed to change. That’s a feature, not a flaw.
You can have a system that works perfectly well without a unified technology platform. You can still ship consistently even while migrating half your code to a new framework. You can operate well with imperfect tooling.
What you can’t do without is the agreement underneath it all.
A Set of Rules, Processes and Tools
The reason I keep returning to that original definition is the order of the words.
Rules first. Processes second. Tools third.
Most teams start from the other direction. They build the tools, assume the processes will follow, and discover later that the rules were never really agreed. The Figma library gets built. The component library gets built. The documentation gets built. And then someone on a new team asks a reasonable question about an edge case, and there’s no answer anywhere, because nobody agreed on the rule behind the component.
A Design System asks you to work backwards from the decision. What do we want to be true about this product? How do we want to make decisions when new problems arise? Only then: what tools will help us do that?
The teams I’ve seen build the best systems weren’t the ones with the most components. They were the ones with the clearest sense of what they were trying to agree on.
Turo López Sanabria has over 20 years of experience in Design, and nearly a decade building the infrastructure that makes digital products coherent at scale. Five Design Systems. Several companies. Today, he works at the frontier where the line between building for humans and building for machines has started to blur.
Read the companion pieces: