What has to be true before AI can reliably consume a design system?
Senior Design Program Manager | AI Readiness
THE PROBLEM
As AI tools became part of design and engineering workflows, conversations quickly centered on evaluating one tool after another. Could it generate layouts? Could it write code? Could it answer Design System questions?
I thought we were starting in the wrong place.
The Design System’s knowledge lived where most systems keep it: documentation, scattered guidance, and the people who answered questions. That worked for humans. It wasn’t a reliable foundation for AI.
THE APPROACH
The conversation kept returning to tools. I kept returning to the Design System.
As the strategy evolved, I consistently pushed the conversation beyond individual AI tools and toward the underlying capability they all depended on. Rather than optimizing for one tool at a time, I focused on making Design System knowledge consumable by people, tools, and automation.
That reframed AI readiness from a tooling initiative to a knowledge infrastructure initiative. Instead of asking which AI tool to support next, we focused on what every AI capability would eventually require: structured knowledge, governance, stewardship, and clear operational boundaries.
My role was to shape that strategy, align cross-functional planning, and define the operating model needed to make Design System knowledge reliable, maintainable, and usable by AI-assisted workflows over time.
THE FRAMEWORK
AI readiness is a knowledge problem.
As AI became part of design and engineering workflows, I found it helpful to separate three distinct systems that were often being treated as one. Each serves a different purpose, has different owners, and matures at a different pace.
Operating Model
Creates knowledge
Defines workflows
Produces standards
Governance
Controls knowledge
Defines ownership
Manages lifecycle
Intelligence Layer
Distributes knowledge
Powers AI workflows
Enables automation
These systems are connected, but they are not the same thing. The operating model creates and organizes knowledge through standards and ways of working. Governance defines ownership, quality, and lifecycle. The Intelligence Layer makes that knowledge available in a form AI can consistently retrieve and apply. Treating them as one problem creates unclear ownership, unrealistic expectations, and an operating model that doesn’t scale.
The Intelligence Layer doesn’t replace documentation or source systems. It connects structured Design System knowledge to AI-assisted workflows so AI retrieves system guidance instead of relying on interpretation. The strategic advantage isn’t the AI tool itself. It’s the intelligence layer behind it.
Once those boundaries were clear, the next question became:
What has to exist before AI can reliably consume the Design System?
01 Machine-consumable knowledge
Consistent naming and cross-platform parity
02 Structure components
Structured guidance, metadata, and relationships.
03 Knowledge stewardship
Named owners keep knowledge current and correct.
04 Governance
Standards, validation, and guardrails.
05 Operational boundaries
Clear ownership across teams
THE KEY DECISIONS
Four decisions shaped the program:
Knowledge before tools. Build machine-consumable Design System knowledge before optimizing for individual AI tools, models, or agents.
Infrastructure before products. Treat MCP, Design System Skills, and the experimental interface as infrastructure that exposes Design System knowledge—not AI products the Design System team is expected to own and support.
Shared foundation before specialization. Build one trusted knowledge foundation that many AI tools can consume instead of optimizing for each new tool individually.
Governance before adoption. Define ownership, success criteria, and guardrails before demonstrations create expectations for production use.
WHAT CHANGED
The conversation shifted from evaluating AI tools to preparing the Design System itself.
Instead of asking which tool to support next, leadership had a framework for evaluating AI investment through organizational readiness rather than individual tools. By creating a shared intelligence layer instead of optimizing separately for each AI tool, the strategy helped avoid duplicated investment, tool-specific rework, and a growing support burden on the Design System team.
Figma Make became a proof point, not the strategy. It demonstrated that when Design System knowledge is structured, governed, and machine-consumable, AI can reliably consume it. The strategy was building that foundation, not optimizing for a single tool.
The Design System was positioned not as the owner of every AI experience, but as the steward of the intelligence layer those experiences depend on.
AI capabilities were built by Design Systems Engineering. My contribution focused on operational readiness, knowledge strategy, governance, documentation architecture, human-in-the-loop adoption, and cross-functional planning.