Design Systems with AI: Tokens, MCP and Governance

AI can now generate a screen, a component or a whole app in minutes. That speed has a side effect every designer has seen: interfaces that work but don't feel like your product. Off-brand colors, invented spacing, a fourth kind of button nobody asked for.

The fix isn't to slow AI down. It's to give it something solid to follow. That something is your design system, and in 2026 the job of a design system is changing: it no longer only serves designers and developers, it also has to be readable by machines.

This article walks through how to apply a design system with AI across product development, from tokens and documentation to MCP servers, governance and a practical checklist.

The idea in one line: the clearer your design system is written down, the more on-brand your AI output becomes.

Why design systems matter more with AI

A language model doesn't "see" your brand. It predicts likely code and layouts based on what it was trained on and what you put in its context. If the context is thin, it fills the gaps with generic patterns.

A design system narrows those gaps. It tells the model which components exist, which values are allowed and when to use what. Without it, every prompt starts from zero. With it, every prompt starts from your product.

There's a second reason. AI makes it cheap to create new UI, which means it is also cheap to create inconsistency. The more people on a team generate interfaces with AI, the more a shared system becomes the thing that holds the product together.

Layer 1: Tokens as the single source of truth

Design tokens are named design decisions: colors, type sizes, spacing, radii, shadows, motion durations. They are the smallest, most machine-friendly part of a design system.

A stable standard now exists. In October 2025 the W3C Design Tokens Community Group published the first stable version of its specification (2025.10). It defines a vendor-neutral file format with support for theming and multiple brands, modern color spaces like Display P3 and OKLCH, and aliases between tokens. It's a community group report, not an official W3C Standard, but it's intended for implementation, and tools such as Style Dictionary, Tokens Studio, Terrazzo, Figma and Penpot support or are adopting it.

Name tokens for their role, not their value. A primitive token stores a raw value, like a hex code. A semantic token describes its purpose, like "color, text, primary" or "spacing, compact". Models choose correctly far more often when the name explains the intent.

Keep primitives (the palette) separate from semantic tokens (what they are used for).
Use one token set as the source, and generate CSS variables, Figma variables and platform files from it.
Define modes (light, dark, high contrast, brand) inside the token system, not as one-off overrides.
Never let AI output contain hard-coded values when a token exists. Make that a rule, then check it.

Layer 2: Document components for humans and LLMs

Traditional component docs are visual: how a button looks in each state. A model also needs the rules: when to use the component, when not to, and how it combines with others.

Figma's own guidance for AI-ready design systems (its "LLM context design" article) describes three layers working together: well-named tokens, specs that state usage rules explicitly, and an audit loop that catches what still slips through.

For each component, write down:

Its purpose in one sentence, in plain language.
When to use it and when to use something else instead.
Its API: properties, variants, allowed values and defaults.
Correct and incorrect examples, with a short reason for each.
Accessibility requirements: labels, focus behavior, minimum target size, contrast.
Content rules: label length, tone, capitalization.

Structure the docs so a model can navigate them. Figma recommends this for Figma Make kits: a short top-level guidelines file that introduces the system and points to more specific files, such as an overview of components, icons, tokens and layout, plus one file per complex component. The same structure works well for any AI tool, because the model reads a map first and the details only when needed.

Write in Markdown, keep sentences short, and prefer rules ("Use the primary button once per view") over descriptions ("The primary button is important").

Layer 3: Connect Figma, code and AI tools

Figma variables. Variables are where tokens live inside Figma. If they mirror your token file, with the same names and modes, designers and AI tools work from the same values. Dev Mode can show each variable's code syntax, so the name a developer sees matches the name in the codebase.

Code Connect. Code Connect maps Figma components to the real components in your codebase. When it's set up, the code shown for a component in Figma uses your actual import and props instead of generic markup. You can also add instructions to each connection, such as prop patterns or accessibility rules.

The Figma MCP server. MCP (Model Context Protocol) is an open standard that lets AI tools connect to outside data and tools. Figma's MCP server gives AI coding agents structured design context from your files: layout, components, variables, styles and assets. When your components are connected through Code Connect, the context also includes real import statements, usage snippets and your custom instructions, so the agent reuses your components instead of rebuilding them. The server can also search connected libraries for existing components and variables, and, with the right setup, write native content back to the canvas. Figma recommends its remote server, hosted at mcp.figma.com, for most users.

AI builders and editors. Tools like Cursor, Lovable and Figma Make each have a place to store persistent instructions: project rules in Cursor, project knowledge in Lovable, guidelines and Make kits in Figma Make. Figma Make kits can bundle your published design system package with its guidelines, and Make can draft those guidelines from your package for you to review. Whatever the tool, the principle is the same: put your design system rules where the AI reads them on every request, not only in a single prompt.

Layer 4: Keep AI-generated UI on-brand

Even with good context, models drift. Treat AI output like work from a fast new teammate: helpful, but reviewed.

Constrain first. Tell the tool to use only components and tokens from your system, and to ask before creating anything new.
Reference, don't describe. Point to a real component or screen ("like the settings page") instead of describing a style in adjectives.
Generate small. One section or component at a time is easier to review than a whole app.
Ask for all states. Loading, empty, error, success, long content and narrow screens. AI often skips them.
Feed corrections back. When you fix the same mistake twice, turn it into a written rule in your guidelines.

Layer 5: Governance and QA

A design system used by AI needs the same governance as one used by people, plus a few automated checks.

Ownership. Name who approves new components and token changes. AI can propose; a person decides.

Contribution flow. When AI or a teammate creates something the system lacks, it goes into a review queue, not straight into the library.

Automated checks.

Lint code for hard-coded colors, spacing and font sizes that should be tokens.
Run visual regression tests on core components.
Run accessibility checks (contrast, labels, keyboard focus) in the pipeline.
Track which components AI-generated code actually uses, to find gaps and drift.

Versioning. Version tokens and components, publish changelogs, and update AI guidelines in the same release. Out-of-date guidelines are worse than none, because the model follows them with confidence.

A workflow from discovery to handoff

Discovery. Use AI to summarize research and cluster insights, but keep decisions with the team. Note which existing patterns the problem touches.
Define. Write the user flow and screen list. Check the system for components that already cover each need.
Explore. Generate quick variations in Figma Make or an AI builder, constrained to your design system kit. Throw most of them away; that's the point.
Design. Refine the chosen direction in Figma with real components and variables. Mark anything new as a proposal.
Prototype. Build a working prototype with an AI tool that has your guidelines loaded. Test it with real content and real users.
Handoff. Developers or coding agents pull design context through Dev Mode and the MCP server, with Code Connect mapping to real components.
Review. Compare the build against the design, run the automated checks, and feed new rules back into the system.

The loop matters more than any single step. Every project should leave the design system a little clearer than before.

Practical checklist

Tokens follow one source of truth, with semantic names and defined modes.
Figma variables mirror the token names and modes.
Every core component has purpose, usage rules, API, examples and accessibility notes.
Guidelines are in Markdown, with a short overview that links to detailed files.
Code Connect maps your main Figma components to code.
AI tools have persistent rules or knowledge pointing to the design system.
AI is told to use existing components first and flag anything new.
Linting catches hard-coded values; accessibility and visual tests run automatically.
There's a named owner and a review flow for new components and tokens.
Guidelines are versioned and updated with every system release.

Conclusion

AI doesn't make design systems less important. It makes them the most important design asset a team has. The system becomes the brief that every AI tool reads before it builds anything.

For designers, that's good news. The skills behind a strong design system, clear naming, precise rules, thoughtful states and good documentation, are exactly what makes AI useful instead of chaotic. Write your system down clearly enough for a machine, and it will usually become clearer for people too.

Sources

Information checked on October 16, 2026.

Design Systems in the AI Era: Applying Them Across Product Development