Design Systems for Agents
A course about making the design system legible to agents and then letting agents do the system work nobody staffs. It covers tokens as machine-readable instructions, DESIGN.md as a source of truth both humans and agents can follow, review gates that keep component taste deliberate, audits that find drift with evidence, syncing tokens across canvas and code, and the end state: a system that maintains itself with humans approving the changes.
Modules6 modules
Last updated2026-06-02
Audience and outcomes
Design system leads, senior product designers, and design engineers who already run a system and want agents to carry the audit, documentation, and maintenance load without eroding quality.
- Structure tokens and naming so agents apply them correctly without per-task reminders.
- Write a DESIGN.md that works as the system's machine-readable contract, not just documentation.
- Run drift and consistency audits across a real codebase with evidence attached to every finding.
- Set component review gates that keep taste decisions human while automating the mechanical checks.
- Keep tokens in sync across Figma, connected canvases, and code without manual re-entry.
- Operate a maintenance loop where the system proposes its own fixes and humans approve them.
Modules
Modules marked Available have full slide decks with speaker notes and narration scripts. The rest show their planned outline until production catches up.
Design Tokens Are Agent Instructions
Tokens stop being a styling convenience and become the primary way the system tells an agent what is allowed. This module covers naming that carries intent, semantic versus raw values, and what happens when tokens are missing or vague.
- Explain why semantic token names change agent behaviour where raw values do not.
- Audit an existing token set for names that mislead or under-specify.
- Define the token rules an agent must follow and where they live in the harness.
DESIGN.md and Machine-Readable Systems
The system needs one document that an agent loads at the start of every session and a human can still read in ten minutes. This module covers what belongs in DESIGN.md, what belongs elsewhere, and how to keep it true.
- Structure a DESIGN.md that covers identity, colour, type, spacing, components, and anti-patterns.
- Decide what belongs in DESIGN.md versus instruction files, tokens, and skills.
- Set up a review habit that keeps the document aligned with the actual codebase.
Component Taste and Review Gates
Agents can produce components quickly; the system survives only if taste decisions stay deliberate. This module covers what to encode as rules, what to keep as human review, and how a contribution gate works when an agent is the contributor.
- Separate mechanical checks from taste decisions in component review.
- Design a review gate for agent-built components, including evidence requirements.
- Encode recurring review feedback as rules so it stops recurring.
System Audits and Drift Detection
Drift is the default state of every design system. This module covers running audits at scale — tokens, components, accessibility, copy — with evidence per finding, and turning audit output into a prioritised fix queue rather than a guilt document.
- Run a multi-dimension audit across a real codebase with an agent.
- Require evidence — file, line, screenshot — for every finding.
- Convert audit results into a prioritised, assignable fix queue.
Token Sync Across Tools
Most teams hold tokens in at least three places: a design tool, a canvas or spec, and code. This module covers making one of them the source of truth and using agents and MCP to keep the others honest.
- Choose a single source of truth for tokens and justify it for your team.
- Set up an agent-run sync from the source of truth to Figma, canvas, and code targets.
- Detect and report divergence instead of silently overwriting it.
Systems That Maintain Themselves
The end state this course aims at: scheduled audits, automatic documentation, proposed fixes arriving as reviewable changes, and a small human rotation that approves rather than produces. Honest about what still needs people.
- Design a maintenance loop where the system proposes its own fixes on a schedule.
- Keep documentation generated from the source rather than written after the fact.
- Define the human roles that remain: approval, taste, prioritisation, escalation.
Books and articles behind this course
The course teaches the practice; the books and articles carry the depth, the sources, and the worked runs it draws on.
The operating model for product designers, design leads, and builders who need to understand what changes when agents join design work.
A practical guide for designers who want to work directly with coding agents without turning it into a programming manual.
- Build a Design Harness Before You Prompt
A practical tutorial for turning design-system rules, project instructions, skills, examples, and QA checks into a reusable harness that keeps agent-generated UI from drifting into generic output — including a file-by-file walkthrough of the harness behind this site.
- Design Tokens Are Agent Instructions
A practical guide to turning color, type, spacing, radius, and component decisions into token files that agents can read, use, and verify.
- Design System Audits With Agents
A deep workflow for finding design-system drift across tokens, components, screenshots, copy, interaction states, and product meaning.
- Design-as-Code: Tokens, .pen, .op and the Diffable Design File
What changes when design decisions live as token JSON and design surfaces live as text files: a worked token-to-CSS case study with a real one-line diff, an honest look at the .pen and .op formats, and a same-day workflow for making design changes reviewable.
- Design Systems That Maintain Themselves (Almost): Agents and Token Sync
Design systems decay between redesigns, not during them. This article traces a real accent-token change across CSS variables, components, and prose documentation, shows the review gate that caught a deliberately introduced error, and lays out the standing maintenance loop an agent can run — plus the deprecation, breaking-change, and taste decisions that stay human.