A design system is almost always pitched as a design-quality initiative. Consistency. Brand. Polish. A single source of truth. All of that is real, and all of it sounds, to the people holding the budget, like a nice-to-have. So the moment money gets tight, the design system goes on the list with the other nice-to-haves. This is the core mistake: design arguing craft in a room full of people talking about numbers.

This system is actually the cheapest engineering decision your company will make.

The system does save designers real time, and it is worth being precise about that rather than overstating the case. A well-built UI kit ships screens faster, holds them consistent, and turns handover from a negotiation into a hand-off. Those savings are real. But they are the savings everyone already sees and already credits to the system, which is exactly why they do not win the argument in a budget meeting. They are also the smaller pool. A design team is a handful of people; the engineering team it feeds is usually many times larger, and engineering time is the expensive resource in software. The most expensive thing those engineers do is decide the same thing twice and build it three times. A button that has been designed once, named once, and built once stops being a decision. Every time someone reaches for it instead of inventing a new one, you have removed a meeting, a review, a round of QA, and a small argument. Multiply that across a year and a team, and the return was not the designer hours, but the recurring engineering time that was being spent without noticing.

That is why I treat a design system as a cost-saving tool first and a quality tool second. The consistency is a by-product. The real product is decisions made once.

One thing the people who sell system rarely admit is that it constrains designers. It takes options off the table. The third button style you wanted, the slightly different spacing, the clever one-off, those get harder and sometimes impossible. Designers feel this as a loss of creativity, because it is one. Pretending otherwise is why designers quietly resist the systems their own leaders build.

But that is the trade, and it is a good one. You give up local creativity and buy a shared language between design and engineering. Once that language exists, both sides move faster, because they stop renegotiating the basics every sprint. The creativity you lose is at the level of the button. The creativity you gain is at the level of the product, because the team’s attention moves up to problems that are actually worth solving.

So if the economics are this good, why do most systems fail? It is almost always for reasons that have nothing to do with design.

The first one is ownership. A design system is a product, not a project. It needs a roadmap, a maintainer, and a budget, the same as anything else you expect to keep working. Most companies fund the build and not the upkeep. So the system ships, the team moves on, the product keeps evolving, and within a year the system is out of date and people route around it. An unmaintained system is worse than none, because now everyone has a reason not to trust it.

And the drift is not only internal. The ground under the system moves too. Figma changes what a component can be, the tokens you hand-built become something the tool now generates for you, AI shifts what is cheap to make and what is even worth making.

The second is the codebase you are walking into. You almost never build a system into a clean product. You inherit a mature one, with hardened opinions and years of decisions baked in, often built and designed by developers, and it shows. Retrofitting a system into that is slow, political work. The system competes with the way things have always been done, and for a while you are running two systems at once, which costs more. People see that cost, do not see the future saving, and conclude the system was a mistake. But, it was only half-finished.

The most common version of this is the team that is convinced it already has a system because it has Tailwind. Tailwind is a styling mechanism, not a system. It will happily carry fifty subtly different buttons, each one locally reasonable. However, the cost behind this is the engineering hours described above. You are not looking for consistent style, but the decision being made once.

The third is that the people who paid for it were sold the wrong story. If you justified the system on aesthetics, it gets cut on aesthetics the first time the quarter looks bad. If you justified it on engineering cost and decision speed, it has a defence that survives a budget meeting.

So if you are building one, or trying to keep one alive, remember a few things.

Fund it as a product. If it does not have an owner and a maintenance budget, you are not creating an asset.

Bring engineering in from the first day, not as consumers of your system but as co-authors of it. Adoption is not a design problem you can solve with better components. It is an agreement, and people adopt agreements they helped write.

Measure the things that actually pay:

1. time to ship a new screen,

2. number of one-off implementations that stop appearing in the codebase,

3. questions engineering no longer has to ask design.

Those are the numbers that keep a system funded.

And be honest about the creativity trade with your designers. A system imposed on them is one they will quietly work around, and a worked-around system is just expensive documentation.

A design system is one of the few things a design team can build that pays for itself. That is exactly what makes it valuable, and exactly what makes it easy to lose. Sold as polish, it dies in the first downturn. Sold as economics, and built as a product, it becomes the rare piece of design work that nobody questions, because everyone can see what it returns.

For a long time I thought that was unfair. Now I think it is mostly our own fault.

Most designers are trained to argue craft. Consistency, accessibility, the right corner radius, user delight. That's not wrong, but almost none of it lands in the room where budgets get decided. The people in that room are asking a different question: what does this team return? If you cannot answer in their language, you are a cost centre with nice pixels. Cost centres get cut.

I came into design through industrial design school, then economics. Industrial design taught me that form follows function. Economics taught me to read it from the other side of the table. Zoom out far enough and form follows function becomes something bigger: design is a business function. It is expected to reduce cost, increase revenue, or take risk out of decisions. Otherwise it is decoration. Good design does the first three. Almost nobody writes about how.

I have spent more than fifteen years helping build software. Carrier apps that shipped on phones people actually owned. Multi-brand platforms that handled real money and real traffic. Design systems retrofitted into mature, developer-shaped products that resist change. Long enough to watch the same pattern repeat across very different companies.

That is what this newsletter is about. Design the way I actually practise it.

Design systems as a shared language between design and engineering: what it saves in build cost, and what it costs in creative freedom. Not a style guide. How design teams get built, scaled, and cut, and what to do about each. Multi-brand and internationalised products, because that is where systems thinking quietly erodes. And the operational work that decides whether good design survives contact with a real company.

I am not a fan of trend pieces or "ten principles" lists. There are enough of those already.

Some of it will be practical. Sometimes I will obsess over a piece of technology I find fascinating. Some of it will be argument, positions I will defend and you are free to push back on. I write to think. Sometimes that means being wrong in public and correcting myself. That is the point.

On rhythm: something every couple of weeks, not a schedule I will break. Hopefully each one is worth your time instead of just filling your inbox.

The first one is coming soon. It is about why design systems are the most misunderstood cost-saving tool in software, and why most of them fail for reasons that have nothing to do with design.

If that sounds useful, subscribe. If not, no hard feelings.