The design system I'd build if I started over

Take a program away. Imagine it doesn't exist yet at the company you're at, no incumbent team, no half-built tooling, no political memory of an earlier attempt that went sideways. Just you, a real product, and the question of how you'd build the program from a blank page. Here's mine for design systems.

The first hire after me wouldn't be another engineer or a typographer. It would be a person whose strongest skill is building relationships and reading what other teams need. The 25/75 split decides this. A library of components, however good, doesn't get used by accident, and the person who can make sure it gets used is rarely the same person who can build it well. Putting that hire off until "we have a system worth adopting" is the standard mistake. By then the system has been shaped entirely by what the engineers thought was important, and the adoption work starts cold.

The second move is to refuse to ship a public version of the library until at least two product teams have shipped a real customer-facing feature on top of it. Private alpha first, with handpicked teams who agreed to take the early discomfort in exchange for being the ones who shape the API. The reason is that a system validated only by its own team has had no contact with reality. Every component decision was made under the assumption that the people who would use it think like its authors, which they don't. Two real teams shipping on it surface the wrong assumptions in a week and a half. Without that, the team builds an aesthetically clean library that needs an overhaul the moment the first product team tries to use it for something the authors didn't anticipate.

The third move is to put adoption work onto the roadmap as line items with due dates, the same as components. Office hours, paired sessions with a product team's engineers, a quarterly check-in with each team to look at what they shipped without the system and why, a regular short demo from a product team showing what they built with it. These have owners and deadlines. They are not what you do when there's spare time, because there isn't spare time, and adoption work always loses to building components when it competes for slack.

What I'd decide before component one

Versioning and breaking-change policy. Whether the library publishes a single semver line or per-package versions. How a breaking change is communicated and what counts as breaking. Most teams discover they have to answer these questions about six months in, after a few breaking changes have already gone out without much warning, which is how you teach product teams that upgrading is risky and lose them for the next year.

Contribution model. The default question being whether a product team can contribute a missing component back, what the bar is, and who reviews. This gets renegotiated forever, but having a starting position written down lets the renegotiation be about substance instead of about process.

Governance for conflicting needs. When two product teams have similar but not identical buttons, whose button wins, and what happens to the team that gives theirs up. The clean-page version of this is a written rubric that the team applies the first time the case comes up; the renegotiation comes later, but the precedent comes first.

None of these are technical decisions. They are decisions about how the system relates to the rest of the org, made before there are any components to argue about, when the disagreements are still in principle and the politics haven't hardened.

What I'd skip

A semantic-token layer that goes deeper than two levels of indirection on day one. The token cathedrals that look impressive in a Figma file are usually a bet that the product is going to need theme switching at a level it doesn't yet, and they make every change three steps slower in exchange. Two levels (primitive and semantic) is almost always enough for the first year.

A Figma library that mirrors the code library perfectly. The cost of keeping them in lockstep is high and the benefit, for the first year, is mostly aesthetic. Designers can work in Figma against a slightly looser version and the code team can ship without waiting for the Figma file to catch up. The two converge after the practice is real.

A glossy public-facing documentation site, polished design principles page included, before there's anything to document. The early version is a Notion page that gets brutally updated as the system settles. A documentation site as marketing comes after the system has earned the right to market itself.

What I'd measure

How often new code in product teams reaches for the system by default. This is a real number you can pull from a codemod or a grep across the monorepo. It's the actual signal. Library size, npm downloads, GitHub stars: those are easier to dashboard and they tell you nothing about whether the system is doing its job.

Whether teams trust the system enough to use a component without first reading its source. This is a vibes question that you answer by talking to people, and it's the leading indicator of every adoption metric that comes later. The day someone tells you they grabbed the system's date picker without checking how it works is the day you know the system has earned its place.

The clean-page version of the program looks a lot like the lived-in one in its eventual shape. The difference is that the work that decides whether the system gets used (the relationships, the contribution model, the trust) is treated as the work, not as overhead the manager handles on the side. Most programs eventually get there. The clean-page one starts there.