The Architecture of Zero

Nobody asked you to build this.

There is no mandate. No budget. No executive sponsor with a slide deck full of commitment. Just you, a blank canvas, and a reasonable question: where do I start?

I was brought in to manage a Sketch-to-Figma transition at a company with an existing-ish design system I had never seen before. The brief was straightforward. Migrate the library. Establish the new tooling. Move forward.

Six months in, I found myself in an argument with the design team about spacing. A specific spacing value. Why it was 12px here and 16px there and 14px in a third place with no apparent logic connecting any of them.

Nobody could answer the question. Not because they were avoiding it. Because there was no answer. Every designer had improvised their own spacing values independently. Nobody had consulted a standard because no standard existed. The system had been built on top of a markup done eight years earlier by a person who had left the company seven years ago.

The foundation had been gone for seven years. We had been building on top of the memory of a foundation.

Two years later, the decision was made to abandon what existed and start a new generation of the platform entirely. Not because the work had been bad. Because by that point, repairing the foundation was more expensive than rebuilding from scratch.

This is the moment most design system stories begin. It is also the moment most of them are already going wrong.

Why Starting With Components Is the Wrong Move

Six months later, the team has two hundred components. And three percent adoption.

The components were not the problem. The sequence was.

Building at the visible layer before the invisible layer exists is the most common mistake in design system work. Not because components are wrong. Because components built on undefined foundations are negotiation documents, not shared agreements. Every decision that wasn't made explicitly gets made implicitly — by whoever builds the next thing.

You cannot build the visible layer before you have defined the invisible one.

The invisible layer is what most teams skip. Not out of negligence. Out of excitement. Because the invisible layer cannot be demoed. It cannot be shown in a meeting. It looks nothing like a design system.

But that's exactly what it is.

The Three Layers Most Teams Collapse Into One

A design system has three distinct layers. Most teams treat them as one.

Layer 1 — The Foundation

The principles. The charter. The token architecture. The explicit decision about what this system is actually for, who it serves, and what success looks like in twelve months.

Layer 2 — The Structure

The contribution model. The governance rules. The naming conventions. The defined relationship between design and engineering — who owns what, who resolves what, who has final say.

Layer 3 — The Components

The buttons. The cards. The modals. The things that can be demoed.

Most teams start at Layer 3. Because Layer 3 is visible. Because Layer 3 can be shown in a slide. Because Layer 3 looks like a design system in a way that a charter document does not.

But a design system without a foundation is not a design system. It is a component collection waiting to become someone else's problem.

What Starting Correctly Actually Looks Like

Three things. In this order. Before any component is built.

First — The North Star Charter

One document. Not a slide deck. Not a vision board. One document that answers four questions: What problem does this system solve? Who does it serve — specifically? What does success look like in twelve months? And what is explicitly out of scope?

Out of scope is the most important field. Because without it, everything is in scope. And a system that tries to solve everything solves nothing.

Second — The Token Architecture

Before the first component — define the tokens. Color. Typography. Spacing. Elevation. Motion. Tokens are not a design tool feature. They are the contract between design and engineering. The agreement that the word "primary blue" means the same thing in the design file, in the codebase, and in the production build.

Without that contract, every component you build is a negotiation waiting to happen.

Third — The Pilot Product

Do not launch a design system. Launch one component. In one product. In production. Find the smallest possible win. The thing that engineering will actually build with. The thing that proves the contract works before you scale it.

One component. In production. Trusted by one engineering squad. That is more valuable than two hundred components trusted by nobody.

The Quick Win: Start With Four Questions

Before the next component — write the charter. Four questions. One document. One hour.

Share it with one engineer before your next design system meeting. Ask them:

"Does this sound like something worth building?"

If they say yes — you have a co-author. If they say no — you have a problem worth solving before you build anything else.

The Argument

The architecture of zero is not the absence of work. It is the discipline to build what nobody can see yet. The teams that get adoption right are almost never the ones with the best components. They are the ones who did the invisible work first.

Disagree loudly. Inspire boldly.

And remind me — falsely if needed — that somewhere a design system started at Layer 1.

Which layer did your team start at?