Design system structure: the 7 categories and the build order
A design system holds or rots based on the order you build its parts. Here are the seven categories every scalable system needs, and the sequence.
A scalable design system is built from seven categories: tokens, components, patterns, layout, accessibility, documentation, and governance. Having all seven is not the hard part. Building them in the right order is, and the order is where most systems go wrong.
We build and govern design systems across more than ten consumer projects. The same gap shows up every time: the parts exist, but they were added in the wrong sequence, so each one fights the others. A component library lands before the token layer. Accessibility arrives as an audit at the end. Governance is an afterthought. The system works in month one and drifts by month twelve. Below are the seven categories in the order we build them, and the failure mode each one prevents.
How we ranked the seven
Three tests decide whether something earns its own category. It has to be referenced by the categories built after it. It has to fail loudly when it is missing. And it has to be ownable by a person, not split across five teams. Anything that fails those tests is a sub-part of another category, not a category of its own.
1. Design tokens (build these first)
Tokens are the named values the rest of the system reads from. They come in three tiers. Primitive tokens hold raw values (a blue is blue-600 = #1A73E8). Semantic tokens assign intent (color-primary = blue-600). Component tokens bind intent to a context (button-bg = color-primary). The point of the three tiers is one edit: change a brand color by updating a single semantic token, and every component that reads it changes with it.
This is no longer a homegrown convention. The W3C Design Tokens Community Group published the first stable version of the token specification in October 2025, and Figma, Sketch, Tokens Studio, and Style Dictionary all read the same format. Tokens go first because everything downstream references them. Build components first and you will hardcode hex values, then spend a rebrand touching three hundred files instead of three. We cover the token-versus-Tailwind trade-off in a separate piece.
2. Components (build these second)
Components are the reusable UI parts: button, input, card, modal, navigation. Brad Frost's atomic model is the usual mental map, where atoms compose into molecules and molecules into organisms. The job of this category is a single source of truth for the button, not fourteen buttons that drifted apart across fourteen screens.
The failure mode is building this category first. A component library with no token layer underneath looks fine for six months, then every value in it has to be retrofitted into tokens by hand. That retrofit is the most common cause of design system drift we see. The second failure mode is volume: a system with three hundred components is harder to keep consistent than one with sixty. We make the case for killing components instead of adding them.
3. Patterns (build these third)
Patterns are UX decisions, not UI parts. They describe how a flow should work: form validation, navigation, empty states, error handling, destructive confirmation. Nathan Curtis of EightShapes draws the line cleanly: components are how something does work, patterns are how it should work. A component is built and shipped. A pattern is guidance you apply while building.
You need enough components before patterns are worth writing, which is why they come third. Skip them and you get a system with consistent buttons and inconsistent flows. Every team invents its own form-error behavior, and the product feels stitched together even when the pixels match.
4. Layout (build this alongside components)
Layout is the grid, the spacing scale applied to page structure, the responsive rules, and a small set of page templates. It reads from the same spacing tokens as the components, so it can grow in parallel with category two rather than waiting.
The failure mode here is subtle. Without a shared layout category, two screens built by two people use 24px and 20px gutters for the same job. The inconsistency is invisible in review and obvious to anyone moving between pages.
5. Accessibility (build this into every category, not last)
Accessibility is the one category that is not a phase. It is a constraint that lives inside the other six. Contrast ratios belong in the token layer. Focus rings and keyboard order belong in components. Skip links and landmarks belong in layout. The European Accessibility Act has been enforceable across the EU since June 2025, which moved accessibility from a nice-to-have to a legal floor for products sold into Europe.
The failure mode is treating it as an audit at the end. A contrast violation baked into a primitive token is one fix. The same violation found after it has spread through forty components is forty fixes. We wrote about designing accessibility-first after the EAA.
6. Documentation (build this continuously)
Documentation is what turns a code library into a system other people use. Curtis's rule is the right one: lead with rendered variations and copiable code, write guidelines in the imperative, and replace walls of text with do-and-don't contrasts. A token nobody can find gets hardcoded. A component nobody understands gets rebuilt.
Adoption is the recurring top challenge in Sparkbox's multi-year design systems survey, and weak documentation is the most common reason for it. A system can be technically excellent and still fail if the people who should use it cannot tell what exists or how to apply it.
7. Governance (define early, enforce once you have a second consumer)
Governance is the contribution model, the versioning scheme, and a named owner. It answers who can add a component, how a breaking change ships, and what happens when two teams need the same thing. You define it early and start enforcing it the moment a second product depends on the system.
Sparkbox found that 36% of teams have no defined process for accepting contributions. Without one, the system forks: each team patches locally, the patches diverge, and within a year you have one design system on paper and four in practice. We run governance across more than ten consumer projects, and it is the category that keeps the other six honest.
The seven categories at a glance
| Category | What it holds | When to build | What breaks if you skip it |
|---|---|---|---|
| Tokens | Primitive, semantic, component values | First | Rebrands touch hundreds of files |
| Components | Buttons, inputs, cards, modals | Second | Fourteen versions of one part |
| Patterns | Forms, navigation, empty and error states | Third | Consistent parts, inconsistent flows |
| Layout | Grid, spacing, templates, responsive rules | Alongside components | Mismatched gutters across screens |
| Accessibility | Contrast, focus, keyboard order | Inside every category | Audit failures and legal exposure |
| Documentation | Usage, do and don't, copiable code | Continuously | Low adoption, parts get rebuilt |
| Governance | Contribution model, versioning, ownership | Early, enforced at second consumer | The system forks per team |
Build order, in one paragraph
Tokens first, because everything references them. Components and layout next, in parallel, both reading from tokens. Patterns once you have enough components for the guidance to mean something. Accessibility woven through all of them from the token stage, never bolted on. Documentation written as you go, not at the end. Governance defined on day one and enforced when the second consumer arrives. Skip the order and you can still ship a system. It just will not scale, and the repair bill arrives about twelve months later.
Sources
Frequently asked questions
- In what order should you build a design system?
- Tokens first, because every other category reads from them. Build components and layout next, in parallel, both referencing the tokens. Add patterns once you have enough components for the guidance to be worth writing. Accessibility runs through all of them from the token stage, and governance is defined on day one and enforced when a second product adopts the system. The order matters more than completeness: a system with all seven parts in the wrong sequence still drifts.
- Do you still need design tokens if you use Tailwind or shadcn?
- Yes. Tailwind's theme config is itself a token layer, but by default it stops at primitive values and skips the semantic tier, so theming and rebrands stay painful. shadcn gives you component code to own, not tokens, patterns, or governance. Both are useful starting points. Neither is a full design system, and treating them as one is how teams end up retrofitting a token layer a year later.
- How many components does a design system need to start?
- Fewer than most teams expect. Start with the ten to fifteen parts that appear on almost every screen: button, input, select, checkbox, card, modal, table, navigation, and a few others. A small, well-governed set is easier to keep consistent than a large one. Add a component when a real screen needs it twice, not in anticipation.
- Who should own a design system?
- A named person or a small team, plus a written contribution model that lets other teams propose changes. Ownership without a contribution model becomes a bottleneck. A contribution model without an owner becomes a free-for-all. Governance is the category that holds the other six together, which is why it has to be assigned to someone, not left to the group.
Studio
Start a project.
One partner for the digital product you need to build. Faster delivery, modern tech, lower costs. One team, one invoice.
Related articles
Why we kill components instead of adding them: the design system diet
Most design systems grow until they break. We treat the component count as a number to keep small. Here is the rule set we use to prune ours every quarter.
Functional UI animation in 2026: the checklist before it ships
The 7 do, 7 don't checklist we apply on every product we ship: durations from 100 to 500ms, opacity and transform only, prefers-reduced-motion honored at the root.
Design system as a service: 6 agency models compared in 2026
Design system as a service is an ongoing engagement: an agency builds, governs, and evolves your system instead of handing it off. Six models compared.