002 essay
State 1 · Classical
The design system built between 2015 and 2025 to serve human product teams. It is the foundation on which everything else rests. It is also the inventory an agent needs before being able to read it.
There is something tricky about talking of State 2 or State 3 before acknowledging what we have built in State 1. The last decade of design systems (from Material Design in 2014 and Lightning in 2015, through Primer, Polaris, Carbon, GOV.UK and the internal systems of most medium-sized organisations) has produced an enormous body of work. The first thing is to honour it.
What it is
State 1 is the design system that invents the discipline. A structured collection of design decisions (tokens, components, patterns, guidelines, voice, accessibility) packaged in a way that several teams can use it without having to rediscover it. Common language. Cognitive economy. Consistency as product value.
Its canonical pieces are well known:
- Tokens: variables for colour, space, typography, radii, shadows, durations. First as JSON, then as Style Dictionary, now as Design Tokens Community Group (DTCG) format 2025.10.
- Components: Button, Input, Card, Modal, Dialog, Toast, DataTable. Implemented once, documented with stable props, versioned.
- Documentation: Storybook or similar. Editorial prose for designers and frontend engineers. Canonical examples per component.
- Contribution: RFCs, design reviews, semantic versioning, changelog.
- Governance: by human convention. Pull requests, reviews, manual approval. Based on trust within the team.
What it does well
State 1 solved real problems. Before the design system, each product reinvented the button. Each team argued the same spacing forty times a year. A rebrand became a two-year project. State 1 brought those costs to near zero inside the organisation that adopts it well.
It also introduced an editorial principle that did not exist before: the design system as an internal product with its own users. Designers and frontend engineers are the customers of the design system. That changes how it is built, with roadmap, research, adoption metrics, and it distinguishes the systems that work from those that turn zombie after six months.
Where it falls short
State 1 assumes a human consumer. Everything in it (the names, the
documentation, the examples, the ambiguity resolution) is designed so
that a person with context completes what is not said. A designer
knows that button.primary means “primary action of the view” even
when it is not written. A frontend engineer knows that space.4 is
“neither as small as an inner inset nor as large as a section
separator” even when no one has codified it.
An LLM agent does not know that. Or worse: it infers, and sometimes
it infers correctly, and at other times it infers a
variant="destructive-outline" that does not exist. The implicit
documentation that makes State 1 viable for humans is what makes it
brittle in front of machines.
The dark mode trap
There is a recognisable symptom. Many design systems thought dark mode would be resolved by duplicating palettes. That was the first big signal that abstractions were not sufficiently stratified: primitive, semantic, component. Whoever had that clear hierarchy added dark mode in weeks. Whoever did not is still fighting with it in 2026.
The same pattern now repeats with agents. Whoever has canonical tokens, strict schemas, contract tests and structured documentation will pass to State 2 in months. Whoever does not will spend quarters unravelling the ball of string first.
The system decomposition
The Mendeleev Method dismantles the design system into six named layers. Each has its contract and its domain of variation. A well executed State 1 already works across five of them; what State 1 lacks to move to State 2 is not new layers, but that the existing ones become auditable by machine.
- Atom = primitive token (
color.red.500,space.4,duration.120). Value without intent. - Compound = semantic token (
color.action.primary,space.input.y). Primitive plus editorial intent. - Rule = human convention in State 1 (pull request, code review, design review). In State 2 it becomes contract test + OPA policy + schema.
- Piece = component with stable props (
<Button variant='primary'>). - Family = a set of related pieces (Inputs, Feedback, Overlays).
- State = temporal behaviour (hover, focus, loading, disabled).
What State 1 lacks is exhaustive cataloguing: that each layer is named and auditable. Storybook covers the piece. Tokens cover atom and compound. The family lives in the documentation. The rule lives in human convention, not in code. State testing is uneven. Exhaustiveness is what separates a mature State 1 from a brittle one.
What to do if you are in State 1
The best thing: stay there, well. Do not jump to State 2 because. Before exposing a system to agents, verify:
- Real stratification: do you have primitive / semantic / component separated, or is everything a flat collection of CSS variables?
- Documentation coverage: does each component have canonical examples, covered states, usage constraints?
- Contract testing: do your tests fail when a prop changes? Or only when the screenshot changes?
- Basic telemetry: do you know which components are used and which are not?
- Consistent nomenclature: can an agent reading your names infer intent, or does it need to read docs?
If those five points are solid, State 2 is a jump of weeks. If not, it is years.