Design Systems as Prompts, Part 3: Designing for Humans and AI
The bigger shift, what I learnt across both experiments, and where this goes next.
AI does not remove the need for design systems. It increases the need for clearer ones.
After two experiments (Part 1 and part 2), running Claude against a Figma kit and then against a Storybook library, that is the single conclusion I would stake the rest of this on. When the system is loose, the model fills the gaps through approximation. When the system is explicit, it has something to inspect, follow, and reuse. The work changes shape once you accept that. The value is not in asking AI to make a design. The value is in building a system clear enough for AI to operate inside.
It is also where the industry is heading. At a recent Figma event in Sydney, Maria and Rachel from the Atlassian Design System team made the same case at enterprise scale: design systems are no longer about consistent, easy-to-implement UI, they are a strategic capability, and the companies that have invested deeply are integrating with AI tooling far faster than those that have not. The talk was a useful mirror. A 35-designer team is now resourcing against many of the same questions a solo experiment surfaces. What follows are the lessons from mine, with their direction of travel alongside.
1. AI does not understand Figma like a designer
A designer can open a Figma file and browse around. They infer where the components live, recognise a demo page, and tell which parts are exploratory and which are production-ready.
Claude does not reliably do this on its own. In my first attempt it only saw the Cover page and assumed the file had no usable components. It needed a direct link to the component frame before the full structure became visible.
The implication is that Figma files have to become more explicit if we want AI to use them well. Page names matter. Component names matter. Frame structure matters. Visible documentation matters. If the source of truth is hidden, implied, or scattered across the file, AI will struggle, and so, quietly, do the humans.
2. Visual similarity is easier than system accuracy
The first generated section looked close from a distance. That was the misleading part.
On inspection, it was not built properly. Styles were ignored. Components were ignored. Typography was off. Spacing was inconsistent. The section even landed on the wrong page.
This is the gap between visual output and design system output. A design can look right while being structurally wrong, and for real system work that is not enough. If a designer has to rebuild every AI-generated output by hand, the workflow saves nothing. The goal is system accuracy, with visual resemblance as a side effect.
3. Components give AI better constraints
The output improved once I created proper components for typography, buttons, tags, and cards, because the prompt could become more specific. Instead of “create a heading that looks like this”, I could say “use the Header component at the H2 variant”. That is a far better instruction. It gives the model a clear object to use, it reduces interpretation, and it makes the result easy to inspect, because the output either used the right component or it did not.
Every visual decision you leave open is a decision the model makes for you, usually wrong. A component is more than a reusable element. It is a constraint that removes guesses.
4. Variables only help AI if they are visible and inspectable
Figma variables are powerful, but Claude did not always read them reliably. It struggled to access the full variable system unless I displayed the variables and styles directly in the file.
This matters because if the model cannot see the spacing system, it hardcodes spacing. If it cannot see radius tokens, it guesses corner radius. If it cannot inspect colour variables, it falls back to raw hex. Each of those creates a quiet mismatch between the system and the output.
For AI-assisted work, variables need to be both technically defined and clearly documented: a visible token page, clearer naming, or a digest the model can reference before building. The principle is simple. If AI cannot inspect the system, it cannot follow the system.
Atlassian have formalised this into what they call a context layer, structured content files that guide AI in decision-making, sitting on top of the core system. Their motion system is being built with the same regard for semantic structure as their other foundations, in their words, so that both humans and AI can understand it. Semantics is the unlock at every scale.
5. Skills turn one-off prompts into a repeatable system
The biggest improvement came when I stopped treating each prompt as a one-off instruction. Skills turned the workflow into something repeatable.
The Skills I built were specific to the UI kit:
Typography
Kit Digest
Page Scaffold
Section Builder
Spacing Rules
They let Claude understand the rules before creating new layouts, and they cleaned up the prompts. Instead of writing every spacing rule by hand, I could ask it to load the spacing rules first. Instead of asking it to rediscover the kit each time, I could ask it to run the kit digest.
This is closer to how design systems should work with AI. The Figma file provides the components. The Skills provide the usage rules. Together they give the model a working environment rather than a blank canvas.
6. Code makes the system more legible
Once the same design system existed in Storybook, the workflow tightened noticeably. Variables, props, and variants are easier for AI to inspect in code than in Figma, and structural mistakes drop.
This surprised me most. The Figma MCP server alone is not sufficient for production-grade work, the exposed API leaves too many gaps. Storybook closes much of that distance, because the system is no longer described visually. It is described literally, in code. Figma makes the design system visible. Storybook makes it executable. AI works best when both layers exist.
This is also where Atlassian have gone further than most: they have built their own design system MCP server to distribute the system into AI tools and agents, from Rovo to Figma Make, and even to update content on their site. The lesson I reached by hand, that the system needs a machine-readable distribution layer, is one they are now shipping as infrastructure.
7. AI is a stress test for the system
An unexpected benefit was that Claude exposed where the design system was unclear.
If it used the wrong component, that made me question whether the component naming was clear enough. If it hardcoded spacing, that made me question whether the spacing tokens were visible enough. If it produced inconsistent layouts, that made me question whether the layout rules were documented properly.
In that sense, AI became a stress test for the design system. A good design system should be usable by designers, engineers, and eventually AI agents. If AI cannot understand the structure, the system probably depends too much on human interpretation.
The Atlassian team landed on the same idea from the opposite direction. Quoting Jules Fleetwood from their team: to identify the rules that help LLMs, you also uncover the rules that help explain these concepts to humans, and that is a good thing. Designing for AI and designing for clarity turn out to be the same task.
Is it worth letting AI build components and layouts in production?
Not yet, at least not unsupervised in Figma. It is still too inconsistent. It still needs careful prompting and inspection, and it still makes mistakes with page placement, component usage, spacing, and typography. In Storybook the picture is more promising, though it still benefits from a designer reviewing the output before anything ships.
The value today sits in exploration and system stress-testing, not unattended production. AI can create component variations, think through edge cases, produce scaffolds quickly, and reveal missing properties or unclear structures. A designer should still review, refine, and approve the final output.
The bigger shift: the design system as a promptable environment
This experiment changed how I think about design systems.
A design system used to be mainly for humans. Designers use it to stay consistent, engineers to build reusable interfaces, product teams to move faster. With AI in the workflow it becomes something else as well: a promptable environment. The clearer the system, the better AI works inside it. It is no longer enough for a Figma file to look organised to a human. It has to be structured so an AI agent can inspect and follow it.
That means:
Clear page names
Clear component names
Clear variant names
Visible token documentation
Proper spacing variables
Reusable layout rules
Component usage guidelines
Repeatable Skills or instruction files
The design system becomes part of the prompt. The prompt is no longer only the text you type. It is the structure of the file, the naming, the token system, the component hierarchy, the documentation, and the workflow. Atlassian describe the mature version of this as an intelligent source of truth, and an AI-native design system: one AI can understand, build with, contribute patterns to, and help maintain.
Design as communication
The more I tested this, the more I realised that AI-assisted design is less about getting AI to make the design, and more about designing the system that lets AI make better decisions.
Designing the interface is one layer. Designing the system is the next. Designing the instructions that let someone else, human or AI, reproduce the system is where things are going.
As Maria put it, design clarifies intent, that is the whole point of design. Working with AI is starting to feel like a new kind of design communication. You describe design without showing it. You turn it into structure, rules, and stories another agent can follow.
Design as storytelling. Design systems as prompts.
P.S. I recently left the studio I founded and am now on the lookout for a full-time role as a Product Designer. Drop me a DM on LinkedIn if you are looking for a designer who thinks in systems and uses AI as part of the workflow.