Methodology
The AI Design Infrastructure Readiness Model
An eight-pillar framework for evaluating whether a design system can function as AI-ready infrastructure. Each pillar is scored 1–5, from Fragmented to Automation-ready.
Most design systems were built for a pre-AI world. The metrics that mattered were adoption, consistency, and time-to-ship. Those still matter — but they are no longer sufficient. Agents and AI design tools generate UI faster than teams can review it. They produce confident-looking output regardless of whether the underlying system is structured to support them. The question is no longer does the system look consistent. It is can the system govern AI output, or will AI accelerate its drift.
This is the model I evaluate systems against. Each pillar covers a structural layer of the system, and each is scored on the same 1–5 scale. The result is a baseline that design systems leads, VPs of Design, and Heads of Engineering can read and act on without translation.
Scoring
The 1–5 scale.
- 1 — Fragmented. The pillar is mostly absent or inconsistent. AI workflows on top of it amplify drift.
- 2 — Emerging. Patterns exist but are not documented or governed. AI workflows produce inconsistent output.
- 3 — Documented. Patterns are documented but not enforced. AI workflows produce mostly-correct output that needs review.
- 4 — Governed. Patterns are documented and enforced in review. AI workflows produce reliable output most of the time.
- 5 — Automation-ready. Patterns are encoded as machine-readable contracts. AI workflows produce output the system can endorse.
Token taxonomy
What it is
The structure of design tokens — primitive raw values, semantic meaning, and component bindings — and the naming, ownership, and governance rules that hold them together.
Why it matters
Tokens are the contract between design and code. They are also the contract between humans and AI tools. A taxonomy that is flat, inconsistent, or undocumented makes every downstream layer brittle — engineers guess, designers freelance, and AI-generated output references token names that do not exist or mean something different than the designer intended.
How to evaluate
- Are there clear primitive / semantic / component tiers, or is everything flat?
- Do names describe meaning (color-text-secondary) or appearance (gray-400)?
- Is naming consistent across modes — light, dark, brand variants?
- Is there a single source of truth, or are tokens duplicated across Figma, code, and docs?
What good looks like
Three-tier taxonomy with strict naming. Semantic tier tied to component bindings. One source of truth — usually Figma variables exported through a pipeline. Modes and themes layer cleanly. Every token has an owner.
What broken looks like
Flat color palette with names like gray-400 referenced directly by components. Token names that mean different things in different parts of the system. Figma variables and CSS custom properties named differently. No clear semantic layer. Designers ship hex codes because the right token does not exist yet.
Figma library architecture
What it is
How Figma libraries are organized — file structure, component sets, variant axes, naming conventions, and the rules for who can publish changes.
Why it matters
Figma is the most-edited surface of a design system. If the library architecture is unclear, contributors create drift in days. AI tools that read Figma context return that drift as if it were the system. Library architecture is the substrate every other pillar inherits.
How to evaluate
- How are libraries split — by surface, by team, by atomic level?
- Do component variants map cleanly to engineering props?
- Is there a single canonical version of each component, or are there forks?
- Are detached instances tracked? Is there a process to fold them back in?
What good looks like
Libraries split by clear domains. Variant axes map to engineering props one-to-one. Detached instances flagged in audits. Publishing is gated through a small group with review responsibility.
What broken looks like
Multiple competing libraries with overlapping components. Variant axes that do not exist in code. Forks of canonical components in product files because the canonical version did not fit. No record of detachments or local overrides.
Component API alignment
What it is
Whether the variants, states, and props expressed in Figma line up with what engineering actually ships in code — and whether the contract between the two is documented and enforceable.
Why it matters
Every AI workflow that crosses design and code passes through this contract. If Figma offers variants engineering does not support, the AI generates impossible UI. If engineering exposes props the design system does not expose, output drifts away from the system. The contract has to be explicit, named, and stable.
How to evaluate
- Does each Figma variant map to a documented prop or state in code?
- Are deprecated props still accepted in Figma but removed from code, or vice versa?
- Where do designers and engineers disagree about how a component should behave?
- Is there a Code Connect or equivalent mapping in place?
What good looks like
Every Figma variant resolves to a real prop. Deprecation moves through both surfaces in the same release. Code Connect or an equivalent enforces the mapping at review time. Designers and engineers reference the same component contract document.
What broken looks like
Figma variants that have no engineering counterpart. Engineering props that designers cannot select. Repeated requests to add variants that already exist under a different name. AI tools that generate confidently-named components that do not actually compile.
Typography and responsive behavior
What it is
The typographic system — scale, line-height, weight, family, fluid behavior — and how layouts respond across breakpoints, container queries, and content density.
Why it matters
Typography is where systems quietly fall apart. AI-generated UI exposes typographic gaps faster than any other surface because models default to dense text and short content. If the type system is implicit, every generated screen needs hand-correction.
How to evaluate
- Is there a documented type scale with semantic roles (display, heading, body, label, caption)?
- Are line-height and tracking part of the token system, or one-off in components?
- Do components handle long-content states, RTL, and language fallbacks?
- Does responsive behavior live in the system or in product code?
What good looks like
Type scale with semantic roles, tied to tokens, applied via component contracts. Long-content states and RTL handled at the component level. Responsive behavior expressed through container queries or breakpoint tokens, not ad-hoc media queries.
What broken looks like
Designers picking line-height and weight per use. Engineering hard-coding font sizes. No documented overflow behavior. Responsive breakpoints differ between Figma and code. Long-content cases fail in production because they were never specified.
Design and code parity
What it is
How accurately the system as designed matches the system as shipped — across tokens, components, variants, states, accessibility behavior, and motion.
Why it matters
Parity is the leading indicator of system health. When parity erodes, AI output erodes with it — because the AI is reading from the design surface but the user is interacting with the code surface. The gap between the two becomes the gap between expectation and reality.
How to evaluate
- Side-by-side review: do shipped components match Figma source for tokens, states, motion, and a11y?
- Where is drift acceptable, and is that documented?
- Are there parity checks in CI or in code review?
- How quickly does a Figma change reach production?
What good looks like
Visual regression in CI. Documented parity exceptions with owners. Token pipelines that propagate Figma changes within a release cycle. Drift is treated as a defect class, not a fact of life.
What broken looks like
Shipped product that looks meaningfully different from Figma source. No automated parity check. Drift is the default state. Engineers and designers maintain different mental models of what the component does.
Documentation system
What it is
Where system knowledge lives, how it is structured, who maintains it, and whether it can be queried by humans, search engines, and AI tools.
Why it matters
Documentation is the substrate AI tools have to read. A poorly-organized documentation system means AI generates output based on cached snippets, blog posts, and tribal knowledge — none of which are governed. Documentation is no longer a nice-to-have; it is the API surface for AI-assisted work.
How to evaluate
- Is there a single canonical home for system documentation?
- Are component pages structured consistently — usage, anatomy, props, accessibility, examples?
- Is documentation versioned alongside the component?
- Can an AI tool read it and return correct, current answers?
What good looks like
One canonical home. Consistent component page structure. Versioned alongside code. Searchable, indexable, and machine-readable. MCP-accessible for AI workflows.
What broken looks like
Three sites, two wikis, and a Notion page. Component pages with different structures depending on who wrote them. Documentation that lags components by months. AI tools that confidently return out-of-date examples.
Accessibility and governance
What it is
How accessibility is built into the system, how decisions about the system are made and recorded, and how contributors understand what is allowed, encouraged, and forbidden.
Why it matters
Accessibility cannot be added later — it has to be encoded in the components and the contracts. Governance cannot be added later either — without it, every contributor invents their own version. AI tools amplify whichever direction the system is pointed: toward accessible, governed output, or toward fast confident drift.
How to evaluate
- Are accessibility behaviors built into components or left to product teams to handle?
- Are there documented contribution paths, review checks, and ownership records?
- Is there a record of why decisions were made — not just what was decided?
- Does the contribution process scale to AI-assisted contributions?
What good looks like
Accessibility encoded at the component level — focus, keyboard, ARIA, contrast — and tested in CI. Documented contribution paths with review. Architectural decision records that explain why. A governance model that anticipates AI-generated contributions, not just human ones.
What broken looks like
Accessibility delegated to product teams to add later. No documented contribution path. Decisions made in Slack and never recorded. AI-assisted contributions that bypass review because the process was not designed for them.
AI / MCP readiness
What it is
Whether the design system can function as deterministic infrastructure for AI-driven design and code generation — exposing tokens, components, contracts, and documentation through MCP or equivalent so that AI tools generate output the system endorses.
Why it matters
Every other pillar is necessary for AI-ready infrastructure. This pillar is the integration layer. Without it, AI tools fall back on generic patterns and the system cannot govern them. With it, AI becomes a force multiplier for the system instead of a force multiplier for drift.
How to evaluate
- Is there an MCP server (or equivalent) exposing tokens, components, and documentation?
- Can AI tools query the canonical source, or are they reading cached or generic content?
- Are component contracts machine-readable?
- Is there a feedback loop from AI usage back into the system?
What good looks like
Tokens, components, and documentation exposed via MCP. AI tools query canonical sources. Component contracts machine-readable and versioned. Usage data flows back into the system as signal for governance.
What broken looks like
AI tools generate UI from training data, not from the system. Designers paste AI output into Figma without it touching the library. Engineers paste AI output into code without it touching the component contract. AI accelerates whichever direction the system is already heading — usually toward drift.
The model in practice
What it looks like run against a real system.
An early-stage product team had me score two Figma libraries and a coded component library against all eight pillars. The results sent the next two weeks into a rebuild of the variable architecture underneath them — that case study covers what the scoring surfaced and what changed because of it.