Bart Dunweg9 min readWe've built design systems for years, and they fail the same way every time: the system gets built, it looks immaculate in Figma and then nobody uses it. The components are usually fine.
What a design system is
A design system is the shared source of truth for how a product looks, behaves and gets built, plus the agreements that keep everyone using it. The component library and the Figma file are only part of it. A useful one has a few distinct layers:
- Design tokens: the smallest decisions, named once. Color, spacing, type, radius, shadow. Change a token and it changes everywhere at once, in Figma and in code, so nothing drifts out of step.
- Components: the reusable building blocks like buttons, inputs, cards and modals. Built once, accessible by default, so nobody rebuilds them a slightly worse way on every screen.
- Patterns: how those blocks combine to solve a recurring job, such as a form, an empty screen or a checkout step. Get these right once and every team stops solving them from scratch.
- Guidelines: the writing that says when to use something, when not to and why. Most systems skip this, and it's the part that decides whether anyone trusts the rest.
- Governance: the rules for who owns it and how it changes. Without them the system rots the moment the product starts moving faster than the core team.
Skip the last two and all you have is a folder of components.
Why most design systems fail
They fail when they're built in isolation. A core team disappears for three months, comes back with a polished library and hands it to designers and developers who were never asked what they needed. It's finished on paper and useless in practice, because adoption was treated as a launch instead of something you design for.
The second way to fail is the opposite. The system ships, people adopt it and then it freezes. The product keeps moving, the system stands still and within a year teams are building around it again.
Start from the product you already ship
Don't design the system you wish you had. Audit the one you're shipping. Put every button, every input, every card side by side and you'll find eleven grays and six button styles that were all meant to be the same one. That mess is your backlog, and it makes the case for the system better than any slide could.
Systematize what repeats first
Resist the urge to cover everything. The value is in the pieces your team reaches for every day, so build those first and build them well:
- The handful of components on nearly every screen: buttons, inputs, links, cards.
- The tokens underneath them, so a color or spacing change is one edit instead of fifty.
- The two or three patterns that carry the product, like the main form and the primary layout.
Ship that, get it used and let real demand pull the rest. A system that earns its keep in week two earns the room to grow.
Write down the why
Anyone can see what a component looks like. What they can't see is when to use it, when to reach for something else and why it exists at all. Without it, people stop trusting the system and quietly override it. So write it down next to the component, not in a wiki nobody opens.
Make contributing easy
A system only the core team can touch will always lag behind the product, and a system that lags gets abandoned. Give every team an obvious way to propose a component, flag a gap or fix a bug. A contribution means the system is working, so treat it that way.
Give it an owner
Someone has to be accountable for the system the way someone is accountable for the product. That is a person or small team who reviews what comes in, keeps the writing honest and says no when a one-off doesn't belong. A committee that meets once a month can't do that. Without an owner, a system rarely breaks visibly; it slowly stops matching the product.
How you know it's working
The number of components tells you little. A system that works is one that stays out of the way:
- Designers reach for an existing component before designing a new one.
- Developers ship a screen faster because the pieces are already there and already accessible.
- New people find the answer in the writing instead of asking in chat.
- The gap between what's in Figma and what's in production keeps shrinking.
Get there and you stop maintaining the system as a separate project; it is simply how the product gets built.
A design system makes your product consistent and efficient to build on: components, tokens and documentation that improve the experience and carry your brand.
