What belongs in a design system before you build a single component

If you want the short answer: before you build a single component, a design system needs its foundations written down as decisions. Color with its roles and contrast pairs. Type with a scale and line heights. Spacing on one unit. The interactive states every element must answer for. And a place where those decisions live in words, not just in a Figma file. Components come after, and they come easier, because at that point they are mostly assembly.

Most teams run this in the opposite order. The system kickoff starts with the button, because the button feels like progress. Three weeks later there are forty components and no agreement on what the second shade of grey means, and every new component reopens arguments the foundations should have closed. I have built systems for a clinical mobile product, for an accessibility-first platform serving readers over fifty, and for the site you are reading right now, and the order below is the one that has survived all three.

Foundations are decisions, not swatches

A color palette is not a foundation. A palette plus the rules for using it is. The difference sounds small and is everything. On this site, orange is not "the brand color", it is the signal for primary actions and signature moments, and a support blue exists precisely so that orange never has to do wayfinding work it would be bad at. Once that rule exists, a hundred later decisions make themselves.

So the first real work is writing roles. Which color means act here. Which one carries links and focus. What sits on what, and at what contrast. For SeniorConnect, a platform for adults over fifty, the contrast pairs were decided before any screen existed, because for that audience readable is not a nice-to-have, it is the product. The same goes for type: a scale is a foundation only when it comes with line heights and a rule for when each step is allowed. And spacing earns its keep the day you commit to one base unit and stop inventing values per screen.

Name these things as design variables from day one, in code and in the design file, with the same names in both. A foundation that exists under two names is two foundations, and they will drift.

States before components

Here is the step almost everyone skips, and the one I would defend hardest. Before the first component, list the states any interactive element must answer for: default, hover, focus, active, disabled, loading, error, and empty where it applies. Decide once how focus looks everywhere. Decide once what disabled means visually and what it means for a screen reader.

Do this and every component afterwards is born complete. Skip it and you will ship a library of components that each handle a different subset of reality, and the gaps will surface in production, one bug report at a time. On Avalon, the clinical product I designed at CureMD, an appointment could exist in eight distinct states, and the system had to name all of them before the screens could be trusted. That is an extreme case, but the lesson generalizes: the states are the honest inventory of what your product actually is. The components are just the states wearing clothes.

Write it down while it is small

The third thing that belongs before components is documentation, and I mean something much lighter than the word suggests. One page. The foundations, the roles, the states, and one line of reasoning next to each decision. Why this contrast pair. Why this base unit. Why focus looks like this.

The reasoning is the part teams forget, and it is the part that keeps the system alive. A rule without its reason has to be re-argued every time someone new joins or someone senior pushes back. A rule with its reason written next to it can be applied, challenged properly, or amended on purpose. I have written before about how systems die of accommodating exceptions; a written reason is the cheapest defense against that, because the no comes from the document, not from a person.

This is also where accessibility enters, and it enters here or it never really enters. Contrast pairs checked against WCAG at the foundation level cost you a spreadsheet afternoon. The same check retrofitted across a shipped component library costs you a quarter.

What to skip at the start

Just as important as the list above is what stays off it. Skip the exhaustive component wishlist; build components when a real screen demands them, not before, because a component built without a consumer is a guess. Skip theming beyond one light and one dark pair until the first pair is stable. Skip the contribution process, the versioning policy, and the governance model; those matter enormously later, and I have argued for them at length elsewhere, but they are answers to problems a young system does not have yet. A one-page document and a person who cares are governance enough for the first months.

The test I use: if removing a thing would not change any shipped screen, it can wait. Foundations, states, and the written reasons all fail that test immediately, which is exactly why they come first.

Questions I get about starting a system

Do I need a design system for a small product? You need the foundations and the states written down, which might be two pages. Whether you call that a design system is vocabulary. The order of work is the same at every size.

Can I extract a system from an existing product instead of starting clean? Yes, and it is often the honest path: audit what exists, keep what repeats, and write the foundations that the good parts already imply. The order still holds, you are just discovering the decisions instead of inventing them.

How long should foundations take? Less time than the first component war they prevent. For this site, the foundations were settled in days and everything since has shipped against them. The point is not ceremony. The point is that the cheap decisions get made while they are still cheap.

The order, in one place

Color as roles with contrast pairs. Type as a scale with rules. Spacing on one unit. The full list of interactive states, answered once. A single page that records the decisions with their reasons, named the same in design and code. Then, and only then, the first component, which by now is not a fight but a formality.

I have shipped this order enough times to trust it, including on the system this site runs on, which you can read in full, decisions and all. And if you are staring at a product that needs this order imposed on it, that is a large part of what my design systems architecture work is. The button can wait a week. The foundations cannot wait until after the button.