Build one – Seven steps in the right order

Everything so far named the pieces. This lesson is the sequence – the order teams actually build them in, why the order isn’t arbitrary, and what changes when the builder is an AI agent and you’re the one directing it.

Furnishing a house is the honest analogy. You walk the rooms and list what’s actually there before buying anything (the audit – how many blues does the product really use, how many almost-16px spacing values). You decide what kind of house it is (principles – three to five statements specific enough to settle a real argument; “clarity over cleverness” resolves a debate, “we care about quality” resolves nothing). Only then the palette and materials (tokens), then the furniture every room needs before the specialist pieces (core components – button, input, layout primitives first; the exotic data-viz widget waits for a screen that needs it). Then how rooms work as rooms (patterns), writing down where things go and why (documentation – written as each layer lands, never retrospectively, because post-hoc docs record what without the why), and finally who may move the furniture (governance – premature before the system exists, essential before the second contributor arrives, because that’s when drift begins).

Try to run it – the wrong turns explain themselves, which is most of the teaching:

You're leading the build – what happens first?

Pick the steps in the order you'd run them. Wrong picks explain themselves – that's the lesson working.

Core componentsGovernanceUI auditPatternsToken architectureDocumentationDesign principles

1. 1·
2. 2·
3. 3·
4. 4·
5. 5·
6. 6·
7. 7·

Seven steps, one defensible order. Start wherever you believe the work starts.

Hold the sequence as a strong default rather than scripture: Figma’s own guide folds audit and principles into one groundwork phase and notes that principles “often emerge later in the process, or evolve as your system matures”. Audit-first is the firm part – it’s UXPin’s literal step one (“Evaluate your current UI inventory and note inconsistencies”), and skipping it means building against an imagined product.

Minimum viable, honestly scoped

For a small product, “minimum” doesn’t mean “incomplete-feeling” – it means narrow and intentional. Concretely: tokens covering colour, type scale and spacing (skip component-level overrides until something genuinely diverges); the components every screen needs (button, input, card, navigation) and nothing speculative; documentation honest about what’s covered and what isn’t; and a governance model as simple as “one person owns changes for now”. The point isn’t sophistication – it’s that the system doesn’t silently drift the day a second contributor joins.

What separates good systems from bad ones is not component count – a 30-component system that teams trust beats a 200-component one they route around. The three real separators: adoption measured honestly (the sharpest finding in the sources: “high adoption metrics don’t mean your design system works. They mean people installed it” – the better signal is teams voluntarily involving the system’s owner early, pull rather than compliance); coverage honesty (a system that says “not built yet, here’s how to request it” keeps people inside it; silent gaps push them out, screen by screen); and a working contribution model – neither bottleneck nor free-for-all – which predicts long-term health better than any snapshot of what’s built.

When the agent builds and you direct

The sequence doesn’t change. The bottleneck moves. Execution used to be the slow part – a human building and documenting forty component states takes weeks; an agent collapses that to nearly nothing, and what remains is judgement at every gate: does this token choice serve the stated principle, is this component genuinely core or a premature nice-to-have, is the agent’s own audit right about what’s inconsistent. An unanchored “build me a design system” prompt samples the statistical average of every system the model has seen – the generic token soup with no point of view. Your job, at each of the seven steps, is the anchor a human co-designer would have supplied: a named reference at the principles stage (“Linear’s restraint, not Material’s expressiveness”), explicit constraints at the token stage (“five colours total, one accent”), and a real review of the agent’s audit and priority order instead of accepting them as fact-finding. Some practitioners now call a system built for this purpose an agentic design system – “less like a Figma library and more like a CI/CD pipeline or database” for an agent to build safely against; the term is 2026-current commentary, still settling, but the underlying shift is the same one the capstone course trains you for.