How to create a design system with AI tools
8 min read
Figma AI design system tools like Motiff, Galileo and Relume have moved from experiments to daily workflow. The best results come when the tool works inside a product boundary that the team has already defined.
Founder of Design Systems Surf
AI can accelerate design-system work from auditing interfaces to structuring tokens, components and documentation.
AI becomes reliable when automation follows product decisions instead of replacing them with generic interface patterns.
Using AI to create a design system is different from asking it to invent one. This article is about how to use AI to build a design system faster without letting the tool guess the logic that holds it together.
PRO
AI can generate the material but not the logic
Consider a team creating a customer onboarding flow. They feed a few reference screens into an AI design system generator. The tool proposes surfaces, progress states, text styles, inputs, buttons and guidance panels. The resulting interface feels coherent because the same treatments repeat across each step.
But coherence in one flow doesn’t mean reusability across the product. A prominent blue action may work in onboarding without establishing whether the same role belongs in account settings or a destructive confirmation. A highlighted panel may support guidance in one step without explaining whether it should become a general container or stay local to that flow.
The output captures one expression of the interface. A design system preserves the reasoning that makes the expression reusable.
Otherwise you end up with a library that looks consistent in a screenshot and falls apart in production.
This is why automation needs a real product boundary. A broad request to create a complete design system asks AI to infer its scope, priorities, platforms, users, accessibility requirements, technical constraints and intended level of reuse all at once. The tool will produce something plausible, but the plausibility is exactly the risk.
A bounded request works differently. It may focus on one Foundation area, one component family or one recurring product flow. The smaller scope gives AI enough evidence to compare existing choices without treating every pattern it finds as a new system rule. Automation should begin with the part of the product the system needs to explain, not with a generic inventory of everything that exists.
Reading the interface for system clues
Once the boundary is clear, AI can help move from scattered interface choices toward a coherent structure. Suppose an e-commerce checkout contains five similar blue values used for the main action, links, focus, selected delivery options and informational messages. AI can collect those uses and propose a smaller primitive palette with semantic roles connected to each context.
The proposal is useful because it makes existing ambiguity visible. It does not determine whether all five uses should become one token. That is a system decision.
Adobe Spectrum separates reusable global values from alias tokens that express a particular use. A global color can remain a stable source value, while an alias such as background-layer communicates the role it performs and can reference different values across themes. This makes the relationship between system role and current implementation visible instead of flattening every repeated color into one interchangeable value.
The same principle applies to typography, spacing, layout, radius, elevation, border and motion.
AI can organize visible choices, but the system still defines what each area means.
This becomes more concrete in Typography Foundation. A type scale is only the visible layer. The product connects sizes, weights and line heights to semantic text roles, hierarchy, responsive behavior, readability, accessibility, AI context and developer handoff. AI can help adapt the scale, but the surrounding structure defines which product hierarchy must survive the change.
Spacing Foundation works the same way. It can support a new system, adapt an existing one or audit inconsistent spacing decisions while keeping the work focused on grouping, component padding, rhythm, density, responsive behavior and implementation. AI can collect repeated values and propose a consolidated scale, but the system still decides which distinctions between grouping, component padding and page rhythm are meaningful enough to keep.
Bounded tasks preserve established decisions
There is a meaningful difference between asking AI to improve a system and asking it to change one part while preserving everything around it.
A bounded task tells AI what may change and what must remain true while it works.
"Improve this color system" leaves the palette, semantic roles, naming, modes and state model open to reinterpretation. Asking AI to adapt the palette to a refreshed brand while preserving role separation, contrast requirements, mode behavior and implementation names creates a controlled change. It reduces the risk of the tool removing a state because it looks unused or collapsing two semantic roles because their current values are similar.
Apple HIG shows how a stable role can remain intact while its visual value changes. Semantic colors adapt across appearance modes, backgrounds, vibrancy and accessibility settings instead of depending on one fixed value. The expression changes, but the responsibility of the color remains.
When cleaner output weakens the system
AI-generated output often looks more systematic than the material from which it started. Token names become consistent, palettes become smaller, duplicate components disappear and documentation follows one template.
That improvement may be useful, but structural cleanliness is not enough to validate a design system.
Two typography styles may use similar values while supporting different semantic roles. Two component variants may appear redundant while representing different content or interaction conditions. Two tokens may reference the same value while needing to change independently in another theme.
Google Material Design organizes its type scale around descriptive roles such as display, headline, title, body and label. Individual styles sit inside that hierarchy rather than behaving as an undifferentiated collection of sizes and weights. Removing styles only because their values appear close could weaken the role structure that makes the scale useful.
Review must therefore test meaning, relationships, accessibility, responsive behavior, localization and implementation fit. These criteria should be defined before generation, rather than applied as a general visual judgment after AI has already shaped the output.
Closing the loop
A reviewed result doesn’t improve the design system if it remains inside an AI chat. Suppose a team replaces a legacy button property with a clearer semantic model. The Figma component is updated, but production code still supports the old property, documentation shows both versions and the next AI task receives examples from before the change. The system now contains several versions of the same decision. The sort of quiet drift nobody notices until someone opens the wrong file six months later.
Automation becomes repeatable when every approved decision improves the context of the next task.
A component change may affect Figma properties, code APIs, documentation, migration notes, examples and AI context. Not every update reaches every representation, but its impact should be understood before the task is considered complete. Documentation platforms like Zeroheight or Supernova can sync with design files and repositories, yet they only stay current when the update process includes them as a required step.
Current context shapes the task, AI produces or applies a proposal, the result is validated and accepted changes update the materials used next. This is one of the core AI best practices for maintaining a design system: treat the tool's output as a proposal that feeds back into the source of truth, not as a replacement for it.
Where to start: Brownfield, greenfield and the first bounded task
The first automation workflow needs a clear source, a limited type of change, defined review criteria and an understood update path.
A team using AI for design system tasks might begin with inconsistent semantic colors, duplicated spacing roles, missing component documentation or a known mismatch between Figma variables and code tokens. The task is narrow enough to review, but significant enough to reveal whether the existing system provides sufficient context.
A structured color audit maps raw values to semantic roles, checks contrast ratios and prepares developer handoff. Tools like Color Foundation can accelerate this without replacing the system decisions underneath.
What if there is nothing to audit yet?
In a greenfield project, the product boundary is the prototype itself. An AI prototype generator with design system support or an AI app builder with design system support can produce initial screens from a brief. The team then treats that output as product evidence rather than a finished system. They inspect which colors repeat, which text styles emerge and which spacing rhythms feel right.
Starting with a prototype doesn’t mean the system will grow cleanly from day one. Most greenfield design systems accumulate scar tissue within weeks: a temporary color that becomes permanent, a spacing value that spreads by copy-paste. The earlier you run a bounded audit, even on generated work, the thinner that scar tissue remains.
Those observations become the first bounded task: "Extract the recurring values from these onboarding screens into a primitive palette with semantic roles for action, text and background." Teams sometimes use Claude or Perplexity to summarize research or generate initial content for design system documentation. The output still needs the same bounded review: check whether the terminology matches the system, not whether the sentences sound correct.
The first useful automation is the one the team can review and repeat without rebuilding its process.
Once the workflow is stable, it can expand to another Foundation, component family or product surface. Each completed task should make the next one easier by leaving the system more explicit than it was before.
Established systems such as IBM Carbon, Uber Base and Shopify Polaris show how semantic roles stay stable while visual values change. Their success stems from making the rationale behind every decision explicit enough to survive future iterations, regardless of whether AI was used to build them.
