Skip to content
27 July 20263 min readDesign systems

What a design system is for when the machine can draw

The bottleneck was never the drawing.

For most of my career a design system earned its keep by saving time. Someone had already decided what a primary button looked like, so I did not have to decide again. The value was easy to measure. Screens per week. That argument is weaker now. A model can produce a plausible button in seconds. It can produce forty of them, each slightly different, each defensible on its own.

The constraint moved

Producing screens stopped being the expensive part. Keeping them consistent with each other did not. I watched this happen on a profiling tool with four squads shipping in parallel. Every squad had the same component library and every squad was fast. Six months in we had three different empty states, two loading patterns, and a date picker that behaved differently depending on which screen you reached it from. Nobody had done anything wrong. Everyone had moved quickly in a slightly different direction. None of it surfaced in a design review, because a design review looks at one screen at a time. It surfaced in support tickets, where someone described a flow that existed in no document we had, because it crossed three squads.

A design system is not a library of parts. It is an agreement about what nobody has to decide again.

The parts that survived were not components

What held across four squads was never the drawing. It was the decisions written next to it. An error message sits above the field. A destructive action never takes the primary colour. Density belongs to the table, not to the person looking at it. Those held because they were short enough to remember and specific enough to check. The components drifted anyway, and it mattered less than I expected.

Four squads, one library. The components drifted. The rule did not.

The system is now an input

Anthropic's Claude Design makes this concrete in a way I did not expect. During setup it reads your codebase and builds a design system from what it finds, then applies that system to everything you make afterwards. The system stops being what you produce at the end of a project. It becomes what you feed in at the start. That is a good change, and it raises the price of a vague system. A model reading an inconsistent codebase will derive an inconsistent system, then apply it faithfully, at speed, to everything.

So the question I ask about a design system now is not how complete it is. It is whether two people reading it would make the same decision.

If this was worth your time, leave it some love.