Methodology

AI + Design Systems

I don't start with the system. I start with shipping. The system emerges from repeated decisions — patterns that prove themselves in production earn the right to become infrastructure. Here's what that looks like when it matures.

The Problem With AI-Generated Design

AI can generate UI fast. But speed without governance creates a specific kind of debt:

  • Plausible-looking components that use the wrong tokens
  • Layouts that approximate the system but don't comply with it
  • Patterns that look right today but drift from the source of truth tomorrow

The output looks convincing at first glance. But it fails every governance check. And worse — each ungoverned output becomes the reference material for the next generation. The system degrades with every cycle.

My Approach: Governance as Enablement

Most design system thinking treats governance as restriction — rules that slow you down. I treat it as enablement infrastructure — constraints that make AI output trustworthy by default.

1. Specifications as Contracts

Every component is defined by a machine-readable spec before it exists visually. The spec is the contract — it defines what is valid and what is forbidden.

Props: what can be configured, and what values are allowed Tokens: which design decisions this component consumes Anatomy: what parts exist and how they relate Accessibility: what ARIA requirements must be met Forbidden: what you must NOT do with this component

This isn't documentation written after the fact. It's the source of truth that generation flows from. If the spec doesn't define it, it cannot exist in the output.

2. Validation Before Generation

Before any component is generated (by AI or otherwise), the spec runs through automated checks:

  • Does the YAML parse correctly?
  • Do the token references actually exist in the token system?
  • Are cross-file references valid?
  • Are accessibility requirements complete?
  • Are any forbidden patterns present?

If validation fails, generation is blocked. This catches errors at authoring time — not after they've shipped, not after they've been copied into 5 other components.

3. Token Architecture as a Constraint Layer

A three-tier token system means the AI never needs to guess a value:

  • Primitives define what's possible (the palette, the scale)
  • Semantics define what things mean ("primary content" not "#032536")
  • Components scope decisions to context ("button/surface" not "teal")

The AI references semantic tokens. If the token exists, the value is correct by definition. If it doesn't exist, the AI can't use it — the validation layer catches the reference to a non-existent token.

The Virtuous Cycle

This architecture creates a self-reinforcing loop:

Governed

Governed system → AI reads governed patterns → generates governed output → feeds back as reference → quality compounds over time

Ungoverned

Ungoverned system → AI reads inconsistent patterns → generates inconsistent output → drift accelerates → quality degrades with scale

What This Looks Like in Practice

Discovery→Spec→Validate→Generate→Ship

A feature request enters as a problem statement. Through structured discovery, it becomes a defined solution with defined states and flows, a component inventory, token requirements mapped, and accessibility requirements defined.

New components get a YAML spec. The spec validates. Generation produces code AND Figma frames — both governed by the same contract. Engineering handoff is generated from the discovery artefact: states matrix, interaction spec, token reference, edge cases.

The result: Zero revisions for "wrong colour," "wrong component," or "doesn't follow the system." The entire category of error is prevented by the pipeline, not caught in review.

Where AI Adds Value (and Where It Doesn't)

AI is good at

  • Generating component code from specs
  • Producing variants at scale
  • Building prototypes using token systems
  • Detecting patterns across a codebase
  • Remediating drift systematically

AI needs governance for

  • Choosing the right component for a context
  • Deciding which variants should exist
  • Determining information hierarchy
  • Making product decisions
  • Understanding why a decision was made

The designer's job shifts — from manually producing artefacts to making decisions, defining constraints, and designing the system that produces artefacts. The AI handles generation. Governance ensures quality. The designer decides what should exist and why.

Principles

  1. Specs before pixels. Define what's valid before producing it.
  2. Validation is non-negotiable. No generation without passing checks.
  3. Tokens are the constraint language. If a token doesn't exist for a value, the value can't be used.
  4. Governance compounds. Every fix improves future output. Every shortcut degrades it.
  5. The system should be authorable, not just consumable. Designers define specs. Engineers consume output. The system translates.

Further Reading

I've written in more detail about this approach on LinkedIn:

I built a design system that generates its own components The pipeline in detail — YAML specs, token tiers, Figma automation, and what 8,153 variable mutations looks like in practice. AI doesn't fix design debt. It scales it. 8 months of lessons integrating AI into production design workflows — where it excels, where it fails, and why governance matters more with AI, not less.
← Try switching the design tokens