Design Systems as Prompts, Part 1: Making Figma AI-Readable
Testing whether Claude Code and Figma MCP can understand a Figma design system well enough to recreate a section accurately.
If AI can access a Figma file through MCP, how much of the design can it actually understand?
This article is the first part of a practical case study on AI-assisted design workflows. I wanted to explore how far an AI agent can go when given access to a Figma file, and what kind of design system structure it needs before the output becomes useful.
More specifically, I wanted to compare two workflows.
The first uses a typical Figma file with basic text styles, colour variables, buttons, icons, and tags. Enough for a designer to understand what is happening, while still being relatively loose as a system.
The second uses a more structured design system. Components are named properly. Typography is componentised. Spacing is tokenised. Radius and layout rules are defined. Components are built with variables. The goal is to make the file easier for AI to inspect, understand, and reuse.
The experiment was intentionally small. I wanted to recreate one section from the kit. It includes:
The section includes:
A tag
A heading
A short description
A button
A two-column card layout
Each card contains an image, title, and body text
Small enough to test quickly. Detailed enough to expose whether AI is actually using the design system, or simply creating something that looks visually close.
The setup
I started with this Figma Community file and recreated the necessary components in Figma. The goal was to understand how much structure a Figma file needs before AI can recreate a design accurately, either in code or directly inside Figma.
The real question was less about whether Claude could generate a section. The more useful question was: how far do we need to structure a design file before AI can reproduce it properly?
For the first test, I set up the file in a way that resembles many design files before AI enters the workflow. There were basic text styles, colour variables, buttons, icons, and tags. The file was understandable to a human designer, although the structure was still quite lean.
Then I asked Claude Code to inspect the file through Figma MCP.
First test: asking Claude to inspect the file
My first prompt was:
access this figma file. first understand the available styles and variables available. next understand what components are available for use. <https://www.figma.com/design/quTquSvRnejZGefbh008i7/Kit-w-o-proper-structure?node-id=0-1&t=HOWpzf3PLPe2so9T-1>Claude came back saying the file was basically a cover-only file. It thought there was only one page called “Cover”, with a thumbnail showcase of the SaaS website UI kit, and assumed the actual components lived in a separate, unpublished Design System library.
That was not the full picture.
Here’s what I found from the file:
---
## File overview: “Kit w/o proper structure”
This is a **cover-only file**. It has a single page (”Cover”) containing a thumbnail showcase of a SaaS Website UI Kit. There are no editable components or frames directly inside this file — just screenshots arranged as a hero image.
The cover screenshot shows the kit includes UI for:
- Navigation bars (light and dark)
- Hero sections with large typography and 3D objects
- Feature/benefit card grids
- Dashboard/app UI panels
- Pricing and CTA sections
- Sign-up flows
---
## Libraries attached to this file
Two team libraries are added, but neither is publishing usable components or variables:
………After I pasted a direct link to the component frame, Claude relooked at the file and discovered the actual structure. This could be a limitation of the model I was using, Sonnet 4.6, or the way Figma MCP exposed the file context.
Either way, this was the first useful lesson. Claude did not understand the Figma file in the same way a designer would. The file structure, page location, component frames, and variables had to be made explicit.
AI needs the source of truth to be pointed out.
Second test: recreating the section
With that context in place, I asked Claude to recreate the demo section.
can you help me create an exact same design as the "everything you need" in the demo page.
so basically it will be a section that aligns center. It starts off with a tag, a heading h2, a description with a large body text. Continues with a 2 col layout each with a card. the card will be a vertical stack as well with an image, h3 text and normal body size
Visually, the result was quite close to the original design at first glance. The rough composition was there. The section had a tag, heading, description, and cards.
Once I inspected the file more carefully, the problems became obvious. The two-column layout was off. The font and kerning were not applied properly. Styles were not used. Components were not used either. The output was visually similar, although structurally weak.
The first attempt felt closer to a visual copy than a system-led build. It exposed a few clear issues:
Claude did not reliably understand the correct page to work in.
It did not automatically use the existing components.
It did not apply typography styles properly.
It did not respect the column structure accurately.
It treated the file more like a screenshot than a reusable system.
The output required manual inspection and correction. The question shifted from can AI recreate this design to what does the design system need to provide before AI can recreate it properly.
Improving the design system
For the next iteration, I made the design system more explicit. I added:
Proper components for each item, including typography headers and text
A proper spacing system
An extended token system, including corner radius and layout values
Components rebuilt with a stricter variable-based approach
The goal was to reduce ambiguity. Instead of letting Claude infer what a heading should be, there would be a heading component, and so on for the rest of the system.
Even with that improvement, Claude Code still struggled to read the full variable system unless the variables were displayed directly in the file. Variables can exist inside Figma, although that does not mean AI can reliably inspect and use them in the way we expect. Once I displayed the variables and styles directly, Claude started to get a much fuller picture.
The design system was no longer just for designers. It also needed to be legible to AI.
Third test: prompting with components and tokens
Once the design system was more structured, I gave Claude a more specific prompt. Instead of asking it to recreate a design visually, I described the structure using components, variants, spacing, and layout rules.
okay now i need you to help me create a section on this page <https://www.figma.com/design/quTquSvRnejZGefbh008i7/Kit-w-o-proper-structure?node-id=4002-921> a 1200 width section with auto layout which is vertically stack side padding of --sp10 and vertical padding of --sp8 it will have a gap of sp-8 between content the top content will be vertically center
1. start with a tag
2. then include a header component at variant of h2
3. then follow by a body component at variant body large
4. follow by a button black s component
This time, the prompt was much more system-aware. It specified the target page, section width, auto-layout direction, side and vertical padding, gap between content, component order, and component variants.
The result improved. Claude was no longer just guessing from the visual design. It had a more specific construction logic to follow.
Then I asked it to build the card component. The result was pretty decent.
Finally, I asked it to build the full section again. The output was much closer to the original design. The structure was better. The component usage was more intentional. The spacing was more consistent.
Prompt quality mattered, although the bigger improvement came from the design system itself. The prompt became better because the system had something specific to refer to.
Fourth test: using Skills as a support layer
Even after improving the components and variables, one problem remained. Spacing relationships can make or break a design. A section can have the right components and still feel wrong if the spacing is slightly off. The distance between the tag and heading, the heading and description, the text group and cards, or the card content itself affects the whole visual rhythm.
At this stage, I realised that components and variables were not enough. Claude also needed reusable rules for how the system should behave.
This is where I started relying on Skills. I created Skills based on this lean UI kit:
Typography
Kit Digest
Page Scaffold
Section Builder
Spacing Rules
These Skills acted like an operating manual for the design system. The design system provided the assets. The Skills provided the behaviour.
Instead of repeating every rule in every prompt, I could ask Claude to load the relevant Skill before creating or adjusting a section. The spacing rules helped Claude understand how different parts of the layout should relate to one another. The typography Skill helped it apply the correct hierarchy. The kit digest helped it confirm available components, variables, and styles before creating anything.
This became one of the bigger takeaways from the experiment.
If components are the building blocks, Skills are the instruction layer. The Figma file tells Claude what exists. The Skills tell Claude how to use it.
Fifth test: trying it on a new section
Recreating an existing design is useful, although it is only one part of the test. The more interesting question is whether AI can create a new component that still feels like it belongs to the same design system.
So I tried creating a new Content Block component set, inspired by an example from Wix.
Create a Content Block component set in this Figma file: <https://www.figma.com/design/quTquSvRnejZGefbh008i7/Kit-w-o-proper-structure?node-id=4002-921&t=HOWpzf3PLPe2so9T-1>
Before writing any code:
1. Run /figma-kit-digest to confirm all component node IDs, variables, and text styles
2. Run /figma-spacing-rules to load the spacing rules
3. Inspect any existing component to understand how Heading and Body instances are sized and structured — use that as the pattern
Component spec:
- Two variants: default to text left, image right and reverse to image left, text right
- Horizontal auto-layout, items vertically centred
- Padding: SP6 on all sides
- Column gap: SP4 between the content
- Image: 200×200 square, fixed size
- Text content: fills remaining width
Text content stack (vertical, SP4 gap between groups):
- H5 Heading, fill width
- Body Medium, fill width
- Button default
Rules:
All spacing must be bound to variables — no hardcoded values
Apply /figma-spacing-rules before marking done
Confirm the intended structure with me
This prompt was more mature and specific than the first one. The component followed the intended structure more closely. It used the spacing logic more consistently. It felt more aligned with the rest of the kit.
AI was still not perfect. It still required inspection, adjustment, and clear constraints. With a properly structured file and reusable Skills, the output became more predictable.
Once the workflow held up on a new component, the takeaways became clearer.
In Summary
AI does not understand Figma like a designer does. It needs the design system to be readable as instructions. Components, variables, naming, structure, and documentation all become part of the prompt.
A loosely structured Figma file can help AI create something visually close. A structured design system helps AI produce something closer to how a designer would actually build it.
The value of AI in this workflow is not just speed. It is also a way to stress-test the clarity of a design system. If the AI struggles to use a component correctly, that can reveal unclear naming, missing documentation, weak spacing rules, or hidden assumptions in the system.
A Figma file can describe how a component should look, although it does not always describe how that component behaves in production. That is where Part 2 comes in. I will take this same idea into Storybook and test whether AI performs better when the design system exists as real coded components, with props, variants, states, and implementation rules.
If Figma makes the design system visible, can Storybook make it executable? Read the Part 2 of the experiment here.
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.