A design system is a product, not a Figma file

Nothing new under the sun

Before there were design systems, there were brand standards. Anyone who trained as a graphic designer knows the brand book: the thick manual that set out how the logo may and may not be used, which colours belong together, how much space a headline needs and what happens to a letterhead when it becomes a poster. Those manuals were never about control for its own sake. They existed so that dozens of people, printers and agencies could produce work that still looked as though it came from one place.

A design system is the same idea, carried into a medium that moves. Tokens are the colour and spacing pages of the old manual, components are the approved layouts, and the documentation is the part of the brand book that explained why. The principles are decades old and well tested. What has changed is that the system now has to survive daily releases, many teams and code, rather than a print run once a quarter.

Organisation, not rigidity

The most common objection I hear is that a system makes design rigid. In my experience the opposite is true. When the recurring decisions are settled, from the spacing between elements to the shade of a warning, the team has more energy for the decisions that actually matter. Rules are a form of organisation. They free attention rather than confine it.

Rigidity appears only when a system stops listening, when a request for a new pattern disappears into silence and people quietly begin to work around it. That is not a fault of having rules. It is a fault of nobody looking after them, and looking after something is precisely what product thinking is for.

Running it like a small product

I treat every system I lead as a small product with its own users. The users are designers, developers, analysts and, increasingly, anyone who builds a screen. Like any product, it has a backlog of requests, a sense of priorities and a release rhythm, so that changes arrive in planned versions rather than as surprises. It also has a single, clearly identified owner, because a system that belongs to everyone in practice belongs to nobody.

Like any product, it needs to be explained. I keep a learning space next to the library, with short notes on why a rule exists and when it is fair to break it. The aim is simple: nobody should have to ask me the same question twice, and a new team member should be able to find their way without a guided tour.

And like any product, it is measured. I look at how often components are detached, how many colours are still typed in by hand and how long it takes a team to build a new screen. Those numbers tell me where the system is helping and where it is in the way.

What changes when you see it this way

Once a system is treated as a product, conversations shift. Teams stop asking whether they are allowed to do something and start asking whether the system already does it. Requests become feedback rather than complaints. Debt becomes visible, because it sits in the backlog alongside everything else. And the system grows in the direction the products need, rather than in the direction of whoever shouted loudest last month.

It also changes how clients see it. A Figma file is an asset that ages. A product is an investment that keeps paying, because every new screen, every new brand and every new platform starts from what is already there. On large projects, that difference is measured in months.

The brand book, grown up

I sometimes think the best preparation I had for design systems was all those years of brand standards, long before anyone in my world used the word token. The discipline is the same: decide carefully, write it down, explain the reasoning and keep it alive as the brand grows. The tools have changed and the speed has changed, but the craft has not. A design system is simply the brand book, grown up and given a team to look after it.