Why I build the design system before the first screen

Every project I have shipped in the last two years started with the same step: I built the design system before I built the first screen.

This sounds backwards. The conventional wisdom is the opposite — design the screen, extract patterns, then systematize. Build the cowpath, then pave it. I no longer believe this.

Why I changed my mind#

When you build the screen first, every component you write is shaped by that one screen's constraints. The button is colored to look good against that hero. The card is sized to fit that grid. The typography scale is whatever happened to feel right that afternoon.

Three screens later, you have three buttons, three cards, three scales — and now the work of unification is a retrofit, fighting against decisions that have already shipped. Every refactor is a tax. Every new screen is more debt.

When you build the system first, every component is shaped by the language, not the screen. The button is colored because the brand says so. The card is sized to fit the spacing grid. The scale is built once, reasoned about once, and then re-used on every screen.

What "design system first" actually means#

It does not mean building Material from scratch. It means:

• Pick the type scale before the first screen.
• Pick the spacing grid before the first screen.
• Pick the color tokens before the first screen.
• Build five or six primitives — button, link, card, input, badge, eyebrow — and prove they compose into the first three screens you have planned.

That is one or two weeks of upfront work. The payoff is that the next twenty screens take less time, not more.

When this is wrong#

When the product is in deep flux — you genuinely do not know what the screens look like yet — the system-first approach calcifies decisions that should stay liquid. In that case, build a quick prototype, learn what you need, then invest in the system.

But once a product has any kind of shape, I do not skip this step. The cost of skipping it shows up six months later, and by then it is too late to do it cheaply.

The cheapest way to start#

A design system does not have to start as a separate library or a Figma file or a Storybook deployment. Mine usually starts as a single tokens.scss file plus a _base-typography.scss that defines the type scale and the leading. That is the entire system on day one. Components arrive as they are needed, and each new component is constrained to compose from the tokens that already exist.

What changes is not the volume of work, but the order. Doing the tokens before the screens is cheap. Doing the tokens after the screens is a refactor — and refactors compete for time against feature work, which is a fight they always lose. The cheapest design system is the one you wrote before anyone had a chance to disagree with it.