The design system checklist: every foundation, component, and state

A complete design system has four layers, checked in this order: foundations decided as roles, not swatches; the full set of interactive states, answered once; components built on top of both; and documentation plus governance that keeps the first three from drifting apart. Miss a layer and the ones above it wobble, because each layer is only as solid as the one underneath it.

This is not a new argument. I have made pieces of it before, about what belongs in a design system before you build a single component and about why systems die of politeness. What follows is the checklist those arguments imply, assembled in one place, so it can be run against a real system instead of read as an essay.

The foundations checklist

Foundations are decisions, not values. A hex code is not a foundation. A hex code with a name, a role, and a contrast pair is. The checklist below is the one I run at the start of every system, from a clinical mobile product to the site you are reading now.

On SeniorConnect, a platform for adults over fifty, the contrast pairs were decided before a single screen existed, because for that audience readable is not a nice-to-have. The checklist above is the same one, generalized past that project.

The states checklist

This is the step most systems skip, and the one that costs the most to skip. Before the first component, every interactive element needs its states named: default, hover, focus, active, disabled, loading, error, and empty where it applies.

The components are the states wearing clothes.

Why states come before components, not after

On Avalon, the clinical product I designed at CureMD, an appointment could exist in eight distinct states. The system had to name all eight before the screens could be trusted, because a physician cannot afford a screen that guessed. Most products are not that extreme, but the discipline is the same at any size: the states are the honest inventory of what the product actually is.

The components checklist

Components are what most teams start with, and the checklist is short on purpose, because a component built without the two layers above it is a guess dressed as a decision.

Skip the exhaustive component wishlist. A component with no real screen behind it is a guess, and guesses are exactly what a design system exists to remove. This is also where WCAG earns its place at the component level: a focus ring and a disabled state that were decided once at the foundation level cost a spreadsheet afternoon to apply. The same check done component by component, after the fact, costs a great deal more.

The documentation and governance checklist

A system with foundations, states, and components still fails without a fourth layer: the written reasons, and the discipline to enforce them. This is the layer that keeps the first three from drifting apart once more than one person is contributing to the system.

The reasons are the part teams skip, and they are the part that keeps a system alive past its first year. A rule without its reason gets re-argued every time someone new joins or someone senior pushes back. A rule with its reason next to it can be applied, challenged properly, or changed on purpose.

Governance is also where the newest source of drift shows up. Generation tools mean more output, produced faster, by more people, with less review per piece. I have written about the guardrails that keeps that volume from dissolving a system into near matches, and the short version belongs on this checklist too:

None of this is a new failure mode. A design system does not usually fail because nobody wrote the foundations. It fails because the exceptions never stop, each one reasonable on its own, and nobody was clearly the person whose job it was to say no.

Running it against a real system

The checklist is meant to be run, not admired. Take the live system behind this site as the worked example: color and type are named as roles, spacing sits on one unit, the states list was decided before the first component existed, and the reasons for each are written down where a reader can check them. Nothing on this page is a claim I have not shipped against.

If a checklist run turns up a gap, that gap is usually cheaper to close now than it will be once more components are built on top of it. That is a large part of what my design systems architecture work is: running exactly this checklist against a system that already shipped, and closing the gaps in the order they matter, foundations first.

Takeaways

Run the four layers in order: foundations as decisions with names and reasons, then every interactive state answered once, then components assembled from both, then documentation and governance that keeps the first three from drifting apart as more people contribute. A gap in an early layer costs more the later it is found, so check foundations and states before counting components. And treat the checklist as a standing one, not a one-time audit, because AI generated contributions and new team members both test it in ways a system that only gets checked at launch will not survive.

Questions people ask about design system checklists