There is a version of the AI design workflow that looks marvellous in a demo and becomes faintly embarrassing by Tuesday.
You ask a model to make a dashboard. It produces twelve cards, three gradients, a tasteful constellation icon and the sort of chart that implies enormous commercial success without troubling itself with units. Everyone nods. Then somebody asks whether it uses the design system, handles permissions, meets accessibility standards or can actually be built. The room becomes interested in its coffee.
We keep giving AI the equivalent of a mood board and then acting surprised when it fails to understand the organisation behind it.
To make AI useful in a serious design workflow, you have to connect it to the places where product judgement actually lives: research, design tokens, components, content rules, code, accessibility guidance, domain language and approval logic. Give it that context and it becomes much more useful than a sketching machine with good presentation skills.
Start with the workflow, not the robot
AI can contribute at several points in a design process, but it should not contribute in the same way everywhere.
During discovery, it can organise interview notes, compare themes and identify gaps worth investigating. It should not be promoted to “customer” because it generated a plausible quote. During definition, it can turn messy evidence into competing problem frames, assumptions and testable questions. During exploration, it can produce variations quickly. During delivery, it can assemble known components, draft specifications, check states and help translate design intent into code.
I have found it more useful to give AI a series of small, inspectable jobs than to ask it to “design the feature”:
Retrieve relevant evidence and constraints.
Propose options using approved patterns.
Explain which rules and sources informed the proposal.
Let a designer judge, alter or reject it.
Validate the result against the system before it moves on.
The last item is the one teams tend to skip. Generation makes work cheap. Validation stops cheap work from becoming expensive work.
This is especially important in complex products. In my work designing an AI co-pilot for contract negotiation, the difficult question was not how to place a prompt box on the screen. It was how the interface should reveal evidence, maintain human control and turn a probabilistic recommendation into a decision someone could defend. The workflow, not the sparkle, was the product.
Can you connect AI to a design system?
Yes, and this is where AI-assisted design becomes substantially less irritating.
A design system contains several kinds of context. Visual tokens describe colour, type, spacing, radius and motion. Components describe available building blocks and their properties. Patterns describe how those blocks combine to support a task. Guidance explains when to use something, when not to use it, and what accessibility or content constraints apply. Production code reveals the uncomfortable truth about what really exists.
An AI tool can use all of this, provided it is machine-readable and reachable.
Figma’s current approach is a good concrete example. Its MCP server can expose design context, variables and component information to compatible AI tools. Code Connect maps published Figma components to their real implementations in React, SwiftUI, Jetpack Compose, Vue and other frameworks. When those mappings exist, an agent can be shown the actual component and its API rather than inventing a suspiciously similar button from scratch.
The practical setup looks like this:
Give tokens semantic names such as
text-critical,surface-raisedorstatus-needs-approval, rather than leaving the model to interpretred-500as a lifestyle choice.Map design components to production components, including properties and supported variants.
Document approved compositions and the awkward states: loading, empty, error, partial success, restricted access and destructive action.
Make accessibility requirements part of the component contract.
Provide good and bad examples, because a model learns as much from boundaries as it does from the happy path.
Connect the design source, documentation and code repository through controlled tools, then require generated work to use those sources.
I have written before about why AI can generate interfaces while a design system makes them usable. The important shift is that the system becomes more than a library for humans. It becomes an interface through which machines can access organisational judgement.
What kind of design system is best for AI?
Usually not the prettiest one.
The best AI-ready design system is semantic, code-backed, documented and governed. It describes meaning as well as appearance. It can answer not only “what is our button?” but “which action is primary here, what permission does it require, how is failure presented and what must remain reversible?”
In practice, I would look for five things.
1. Semantic tokens
A raw value tells the model what something looks like. A semantic token tells it what the value is for. That distinction lets themes change without the meaning collapsing. It also allows an agent to reason about risk, hierarchy and state. Design tokens are becoming product infrastructure, not merely a more organised way to store hex codes.
2. Real component mappings
The Figma component and the production component should have an explicit relationship. Names, properties and variants need to agree. If design offers Button / Primary / Destructive while code offers BigRedThing, the AI is not the only participant having a difficult day.
3. Composable patterns
AI works better with small, clear primitives and documented ways of combining them. A monolithic “AI assistant” component is less useful than reusable patterns for evidence, progress, approval, revision, tool activity and recovery.
4. Behavioural rules
An AI design system must encode more than layout. It should say when a person must approve an action, when sources are required, how uncertainty appears, what gets recorded and how the user can undo the result. My piece on the AI design system goes further into these behavioural layers.
5. Maintenance and evaluation
Agents will expose every ambiguity in the system at industrial speed. Treat their mistakes as design-system feedback. If the model repeatedly misuses a component, the guidance, naming or API may be unclear to humans too.
Those “NPCs” are probably MCPs
Unless somebody is proposing a design team staffed by non-player characters, the term you are hearing is likely MCP: Model Context Protocol.
MCP is an open standard for connecting AI applications to external systems. An MCP server can expose resources for the model to read, tools it can call and structured prompts that guide common work. Think of it as a standard socket between an AI agent and the useful parts of your working environment.
For a designer, that could mean one connection to Figma, another to a code repository, another to research in a document store, and another to a component registry. The agent can fetch the actual design variables, find the production component, inspect its usage guidance and assemble a proposal with considerably less improvisational jazz.
This does not mean giving a model the keys to everything. Connections should be scoped, authenticated and preferably read-only until an action genuinely requires writing. The difference between “inspect our component library” and “update every component library” is the difference between assistance and a small organisational event.
MCP solves the plumbing. It does nothing for taste. The quality of the context, and the rules governing its use, still determines the quality of the outcome.
Can external libraries give AI taste?
Sort of, although “taste” is doing heroic work in that sentence.
Libraries and registries can give an agent a stronger prior: a collection of well-made components, motion patterns, layouts and conventions from which to work. shadcn/ui registries, for example, can distribute components, hooks, templates, rules and other files in a structured format. Its MCP server lets compatible assistants browse and install items from configured registries using natural language.
That makes a private company registry particularly interesting. A team can publish its approved components, feature kits, tokens, prompts and conventions under a namespace. The agent can then be instructed to use the organisation’s registry before reaching for public alternatives.
Public libraries such as Vercel’s AI Elements, AICSS and other component collections are useful references for patterns that ordinary design systems may not yet cover: streamed responses, reasoning summaries, tool calls, prompt inputs, agent progress and generative surfaces. They can widen the vocabulary available to a team.
They do not automatically provide taste. Combining four fashionable libraries is an efficient way to produce a product that looks as though four fashionable libraries had an argument. Curation remains the design job: select useful patterns, adapt them to your principles, test them with real content, then bring the approved versions into your own system.
What large organisations are actually doing
The better examples are not treating AI design as a single component or a yearly inspiration deck.
IBM Design for AI combines principles, ethics, conversation guidance and an AI Essentials framework covering intent, data, understanding, reasoning and knowledge. The useful lesson is structural: AI practice sits alongside IBM’s broader design language, accessibility and Enterprise Design Thinking. It is part of how teams work, not an ornamental lab in the basement.
Google’s People + AI Guidebook organises practical patterns around user need, mental models, explainability, trust, feedback, control and graceful failure. It makes clear that designing AI involves expectation-setting and recovery, not simply arranging the answer attractively.
Microsoft has been developing Copilot experiences through Fluent and shared interaction guidance across products. The strategic idea is consistency: users should not have to relearn what AI is doing, what it can change or how to interrupt it every time they move from one tool to another.
Figma is approaching the problem from the workflow itself. Its MCP and Code Connect tooling makes design files, variables and production component mappings available to agents. That is a significant move because it turns the design system into executable context rather than a gallery the AI can admire from outside.
None of these organisations appears to think that “buy one AI tool” counts as a strategy. The work is more prosaic:
define where AI creates useful leverage;
connect it to approved knowledge and systems;
standardise how AI behaviour appears in products;
govern permissions, provenance and human approval;
evaluate outputs against user and business outcomes;
train teams to supervise the system rather than merely prompt it.
So an AI strategy for design is partly about tools, partly about design-system architecture and mostly about how the organisation works.
A practical workflow you could implement now
Imagine asking an agent to design an approval panel for a generated contract change.
Without context, it may produce a modal containing “Approve” and “Cancel”, perhaps with a tasteful purple glow. With an AI-ready workflow, the agent first retrieves the approval pattern, semantic tokens and contract terminology. It finds the real ApprovalSummary, EvidenceList and RiskBadge components through the registry. It checks which actions need confirmation, uses the design-system mapping to assemble them in Figma or code, and validates the result for keyboard access, content completeness and supported states.
The designer then reviews the decision: Is the risk explained? Is the evidence sufficient? Can the action be reversed? Does the user understand what changes after approval? The AI handles retrieval, assembly and checking. The designer handles consequence.
To get there, start small:
Pick one recurring workflow with clear boundaries.
Clean up the relevant tokens, components and names.
Document the normal, error and edge states.
Map design components to production code.
Expose only the necessary sources through MCP or another controlled connector.
Create three or four benchmark tasks and examples of acceptable output.
Review every result, record failures and improve the system, not just the prompt.
Do not begin by connecting the model to the entire company and asking it to “be on brand”. That is not an implementation plan. It is the opening scene of a fairly avoidable incident report.
The design workflow becomes a context workflow
AI is already making it easier to generate screens, prototypes, specifications and code. Useful, certainly, but not much of an advantage once everybody can do it. The more durable gain comes from making the reasoning inside a good product organisation available at the moment work is created.
The mature workflow gives AI access to the right evidence, the right components and the right constraints. It asks the model to show its sources, use approved patterns and submit its work to checks. It keeps consequential decisions visibly human.
That changes the role of the design system. It becomes more than a shelf of reusable parts. It becomes a shared account of how the product should behave, used by designers, engineers and machines alike.
AI does not need unfettered creative freedom to improve design work. It needs context, boundaries and a well-maintained route to the good stuff.
Rather like the rest of us.
