We mistake what we can see for the system
If someone asked you to show them your design system, what would you open first?
Probably your component library. Buttons. Inputs. Cards. Navigation. Its the obvious place to start. Its visual, its tangible and its impressive. But I think its also the least interesting part of the system.
That might sound strange coming from someone whose job revolves around design systems, but the more time I spend building one, the more convinced I become that the components are simply the interface to the system. They're not the system itself.
But components are only the visible result
We've mistaken the interface for the product
I think this happens everywhere in digital products. We naturally focus on the thing we can see. The screens. The buttons. The colors. The animations. But people dont engage with products because of the interface. They engage because the system behind the interface solves a problem.
A thought that's been sitting with me recently is this:
People don't engage with systems because of the UI. The UI gives them the handle to interact with the system, but they engage because the system solves a problem for them in a way that they can understand and quantify.
I think the same applies to design systems. Nobody adopts a design system because it has beautifully organised buttons. The buttons can be anything and can look in any way, and are just a means to an end. They adopt it because it solves problems.
It reduces ambiguity, creates consistency, makes accessibility easier, helps teams move faster and reduces the number of decisions people need to make.The components simply become the handle through which people access those benefits.
What lies underneath the pretty interfaces
Because the real work happens around them
Every component exists because dozens of decisions have already been made.Someone decided:
why it exists
when it should be used
when it shouldnt
which accessibility requirements it needs to satisfy
how it behaves
how it interacts with other components
what principles it represents
what problem it solves
The component is simply the visible result of those decisions. That's why two companies can both have a Button component and still have completely different design systems. The button isn't the system. The thinking behind it is.
Building something as simple as a button in a design system needs to account for many other decisions to become usable.
A design system is really a system for making decisions
Ironically, creating the component is often the easy part. The difficult questions begin afterwards.
Where should people use it?
What existing patterns should reference it?
What guidance needs updating?
How does it affect accessibility?
What does it replace?
What depends on it?
How will people discover it?
How do we stop three different teams creating slightly different versions six months from now?
None of those questions are answered by the component itself. They're answered by the system around it.
The structure whose end result is the interface
And those decisions matter more as the system grows
This is the biggest shift in my thinking.
I no longer think of design systems as libraries. I think of them as systems for making better decisions. The components are simply one output of those decisions, while the real product is the shared understanding that hundreds of people can rely on.
That's why documentation matters, why principles matter, why governance matters, why accessibility guidance matters, why naming matters, why relationships matter. Because every one of those things helps people make the right decision without needing to ask someone else.
The system is built from many decisions, goals and constraints. This is what shapes how the components will look like and behave.
So maybe we've been measuring the wrong thing
I've been building a design system intended to work alongside AI and, interestingly, AI made me appreciate the components even less. Not because they don't matter, but because AI can generate components remarkably quickly. What AI struggles with is understanding the reasoning behind them.
Why does this pattern exist?
Why shouldn't this component be used here?
What trade-off did we make?
Which principles apply?
What else changes if this changes?
Those questions don't live inside the component. They live inside the system and I increasingly think that's where AI can provide the most value. Not generating another button, maintaining the knowledge that allows the right button to exist in the first place.
A button is more than just a button
Because the interface was never the product
We often celebrate design systems by counting components.
200 components.
500 components.
Thousands of variants.
I'm starting to think that's like judging a book by the number of pages. The interesting part isn't how much you've built, its how much understanding you've created.
Could a new designer join tomorrow and make good decisions?
Could an engineer understand why something exists?
Could a product manager understand the trade-offs?
Could AI understand enough of the system to help maintain it?
Those questions feel much more important than how many components sit inside Figma.
The real system is everything that makes the interface possible
The interface is simply where people touch the system, that much has always been true for products and I think its equally true for design systems, but the components aren't the design system.
They're the interface through which people interact with it.
The real system is the collection of principles, decisions, relationships and knowledge that produced those components and perhaps that's why building design systems has changed how I think about product design altogether.
The interface is rarely where the real work happens. Its where the real work becomes visible.
UI vs the actual system
So what could your system least afford to lose?
I'd leave you with one question.
If you had to remove one part of your design system tomorrow, which loss would be the most disastrous for your organisation?
And perhaps more importantly...
Why?