Skip to content
Sign in
Design Systems for Agents

Make the design system legible to agents — then let them carry the chores.

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.

Pay once. Yours to keep, with updates.

US$39One-time purchase

Buy courseDesigner TrackEverything bundle

Buying for a team? Team seats

Modules
6 modules
Total time
≈4h 35m
Last updated
2026-10-09

Curriculum

6 modules

Slides are the lesson; study guide and transcript come with each module.

Time commitment

≈4h 35m

About ≈5 hours across the full outline — work at your pace.

Access

US$39

Pay once. Yours to keep, with updates.

What you will build / 01

Artefacts you can take back to the team.

Tokens as instructions, DESIGN.md as contract, audits with evidence, and a maintenance loop humans still approve.

01

Token and naming structure agents can apply without per-task reminders

02

A DESIGN.md that works as a machine-readable contract

03

Drift audits with evidence attached to findings

04

Component review gates that keep taste human

05

A maintenance loop where the system proposes fixes and humans approve

Row of cream, mustard, forest, cobalt, and black colour cards linked by cobalt thread with a forest-green wax seal on warm paper
Curriculum / 02

Module outline

Open the first module you have not finished. The slides are the lesson. The study guide and the transcript are the same module if you would rather read.

01

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.

02

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.

03

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.

04

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.

05

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.

06

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.

Inside the materials / 03

Sample lesson & slide previews

Titles and diagrams from early modules — the same materials you open after checkout.

Two-row diagram comparing a token-backed path with a hardcoded path. In the top row, a semantic token named color.status.escalated.foreground is defined in the token source file, built into a generated CSS variable, read by the agent along with its description, and referenced as a CSS variable in the generated component, leading to an outcome card stating the code stays in sync with the system. In the bottom row, no token contract exists, the agent guesses a plausible raw value, the component carries a hardcoded hex value with no link to the system, and the outcome card states the value drifts when the system later changes.Grid of nine cards, one per section of a machine-readable DESIGN.md: colour, typography, spacing, layout, components, motion, voice, brand, and anti-patterns. Each card states what the section declares and what the agent does with it — for example, colour declares the palette and semantic roles and the agent maps every fill to a named token; components declares primitives and usage rules and the agent reuses existing components before building new ones; anti-patterns declares what the system refuses to do and the agent checks its own output against that list. Colour, typography, spacing, layout, and motion are marked as token-backed sections; components, voice, and brand as usage and asset sections; anti-patterns as the refusal list.Pipeline diagram of contribution review gates. An agent proposes a component change on a branch and assembles an evidence packet of screenshots, states, and token usage. The change passes through automated checks — token audit, type check, lint, accessibility — whose failures return to the agent. It then reaches taste review, a human-led gate judging density, hierarchy, restraint, and voice against DESIGN.md, producing findings with severity and evidence. The system maintainer decides: accept, accept narrowed, redirect to composition, or decline, with reasoning recorded. Recurring findings are written into rules and checks, and a dashed line returns to the start: the next proposal meets a stricter gate.Flow diagram of a design system audit run. A human-defined scope and reference feeds an agent-run fan-out script that dispatches one read-only auditor agent per component or page. Example auditor cards show evidence-backed findings: a raw colour in Button.tsx, an off-scale gap in pricing.tsx, and a duplicated card component. Findings merge into a drift report ranked P0 to P3 with file, line, and evidence per finding, which passes through a human review gate where mechanical fixes are approved as reviewed diffs and recurring findings become harness rules. A dashed line returns from the gate to the scope, showing the workflow rerun on a schedule as a trend line.

Design Tokens Are Agent Instructions · concept

Agents need decisions, not vibes

Design Tokens Are Agent Instructions · comparison

Raw values vs semantic tokens

Design Tokens Are Agent Instructions · concept

Naming that carries intent

Design Tokens Are Agent Instructions · comparison

Where tokens live

Design Tokens Are Agent Instructions · concept

What agents do when tokens are missing

Design Tokens Are Agent Instructions · diagram

The token's journey vs the hardcoded value's journey

Audience and outcomes / 04

By the end of this course you can…

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.

01

Structure tokens and naming so agents apply them correctly without per-task reminders.

02

Write a DESIGN.md that works as the system's machine-readable contract, not just documentation.

03

Run drift and consistency audits across a real codebase with evidence attached to every finding.

04

Set component review gates that keep taste decisions human while automating the mechanical checks.

05

Sync token mirrors from one source of truth. Figma writes stay beta until you re-check that they have graduated. DESIGN.md and skills are what travel.

06

Operate a maintenance loop where the system proposes its own fixes and humans approve them.

Who it is for

This is for you if…

  • Design system leads and design engineers who already run a system
  • Senior product designers owning consistency across product surfaces
Who should skip it

This is not for you if…

  • Teams without any system or token source of truth yet — start with Fundamentals
  • People looking only for a Figma plugin tour
Why register now

The practice compounds. Waiting does not.

01

Agents that cannot read the system invent a second kit. Fixing that once pays for every later course.

02

Audit and documentation load grows with every new surface — this is the work nobody staffs.

03

Token sync and contribution gates are team infrastructure, not a personal tip.

Price and checkout

Pay once. Keep the course, with updates.

Prefer the full designer catalogue, or designer plus leadership? Upsell paths use the same checkout you already trust.

Pay once. Yours to keep, with updates.

US$39One-time purchase

Buy courseDesigner TrackEverything bundle

Buying for a team? Team seats

FAQ

Before you register

Do I need a mature design system first?

You need a real system in use — tokens, components, and some ownership. The course is not a from-scratch system bootcamp.

Is this a subscription?

Pay once. Yours to keep, with updates. There is no renewing membership for new purchases.

What do updates cover?

All edits and new lessons in an owned course, for the life of the course. Bundles include new courses added to that track for 12 months.

What if a course is retired?

Course retirement gives access to its replacement.

Related material / 05

The sources behind this course.

The course teaches the practice; the books and articles carry the depth, sources, and worked runs it draws on.

The Agentic Designer

The operating model for product designers, design leads, and builders who need to understand what changes when agents join design work.

Claude Code for Designers

A practical guide for designers who want to work directly with coding agents without turning it into a programming manual.

Quality, Systems, and Accountability

The three leadership courses are sold together for US$300. Designer courses and bundles don't include them, except the Everything bundle, which does. This purchase doesn't open the designer courses.

View course

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.

Read article

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.

Read article

Design System Audits With Agents

A deep workflow for finding design-system drift across tokens, components, screenshots, copy, interaction states, and product meaning.

Read article

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.

Read article

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.

Read article