What Happens When AI Builds the Design System?
An experiment in building a design system for AI, with AI — while keeping humans in control of the decisions.
The objective
What happens when AI is asked to do something designers have traditionally been responsible for: define, structure and build a design system?
I wanted to explore what it takes to build a design system for AI, with AI—while keeping human intent and decision-making in control. This isn’t about replacing the traditional design system. It’s an experiment to understand what needs to change when AI becomes one of its consumers.
The setup
Before building the design system, I needed a baseline to test it against. I rebuilt an assignment listing screen on claim processing from an old project wireframe, then created a moodboard in Claude Design and refined the screen against it.
This became the reference point for comparison when I would test the output from AI native design system. I used Claude Design to build the system and ChatGPT as a reasoning partner to challenge and structure my decisions. The illustration below summarises my workflow for this POC
From here, the experiment is divided into 3 parts— laying foundations, building components and testing consumption. Each part explores a different question in building an AI-native design system. Pick the one you’re most curious about using the jump links below.
Intrested in seeing the system?
Claude Design’s Design System project isn’t public yet, but you can explore the exported version I’ve hosted on GitHub.
Part 1 — Laying the foundations
In a Figma-based design system, tokens can live in variable collections while much of their meaning and usage is understood through the designer’s interpretation of the system. Here, AI was the primary consumer. So in order to make those relationships, purposes and usage rules explicit, I followed the steps mentioned in the table below.
| # | Step | Intent & Approach | Outcome |
|---|---|---|---|
| 1. | Define Primitive Tokens | Established foundational values for colour, typography, spacing, radius, elevation, borders and icons, with the intent of creating a controlled vocabulary that AI could consistently reference rather than infer visual values. | ✅ Worked — primitives provided a stable foundation. |
| 2. | Create Semantic Tokens | Mapped primitive values to meaningful roles such as surface, text and border, with the intent of giving raw values contextual meaning that AI could understand and reuse. | ✅ Worked — the semantic layer became the bridge between raw values and component usage. |
| 3. | Make token relationships explicit | Added Purpose Rule and Consumed By Rule to make the intent behind each semantic token and its relationship to the rest of the system explicit for AI consumption. | ✅ Worked — relationships became explicit enough to be reasoned about. |
| 4. | Test primitive → semantic propagation | Changed a primitive token to test whether its dependent semantic relationships were actually connected and would propagate, rather than simply being documented as relationships. | ✅ Worked — gave me a practical validation of the token hierarchy. |
| 5. | Create a separate Semantic Relationship Matrix | Explored a dedicated artifact to make relationships between semantic tokens easier for AI to consume, with the intent of creating an explicit relationship map. | ❌ Scrapped — the Semantic Tokens page already performed this role. |
| 6. | Organise the foundation layer | Reorganised the foundation content into a tab-based structure so related token categories could remain accessible without introducing a deeper navigation hierarchy. | ✅ Worked — improved both scanability and system organisation. |
The carousel below shows how this phase was built step by step, following the approach outlined above. I’ve also documented the prompts used at each step in a detailed prompt log, which you can view here →
What I learned?
- AI-native doesn’t mean starting from scratch. The basic Primitive → Semantic model is still familiar from Figma. The difference is that AI needs the intent and relationships to be much clearer.
- More documentation doesn’t always help. What mattered was documenting the decisions and relationships that weren’t obvious. Repeating the same information everywhere just added noise.
Part 2 — Building the components
In design systems, usage guidelines tell designers when and how to use a component, but designers can still make exceptions based on the context. For AI to make those choices, I needed to define more than how a component looks.
I needed to capture its purpose, usage, variants, states and key rules. My first attempt was to document each component in detail, but that quickly became repetitive and time-consuming.
This led me to create an excel based Component Definition Matrix — a structured way to capture the same essential information for every component without documenting everything from scratch.
The table below outlines the approach followed for building components
| # | Step | Intent & Approach | Outcome |
|---|---|---|---|
| 1. | Identify component inventory | Used the baseline UI to identify recurring UI elements and determine which should become reusable components. The intent was to establish the initial component vocabulary rather than create components arbitrarily. | ✅ Worked — gave me a clear set of components to build and test. |
| 2. | Define component structure and behaviour | Broke components down into their anatomy, variants, states and relationships with the foundation layer. The intent was to move beyond visual appearance and make the component understandable as a system object. | ✅ Worked — AI could better understand what made each component reusable. |
| 3. | Document components individually | Tried documenting each component separately with detailed purpose, usage, states, properties and guidance. The intent was to give AI enough context to make the same decisions a designer would. | ❌ Scrapped — the approach became too time-consuming and repetitive as the component library grew. |
| 4. | Test component consumption | Used the components in a real UI rather than evaluating them only in isolation. The intent was to see whether AI would actually reuse the defined components and their underlying tokens when creating an interface. | ✅ Worked — exposed where the system was being consumed correctly and where AI still needed explicit direction. |
| 5. | Create a Component Definition Matrix | Replaced component-by-component documentation with a structured matrix capturing the essential knowledge AI needs: purpose, anatomy, variants, states, usage and relationships. The intent was to create a scalable knowledge layer without manually writing extensive documentation for every component. | ✅ Worked — reduced documentation effort while making component intent more structured and reusable. |
| 6. | Organise the component library | Structured the components into a predictable hierarchy so both designers and AI could locate and understand them consistently. The intent was to make the system easier to navigate and consume. | ✅ Worked — improved discoverability and gave AI a clearer component hierarchy. |
The carousel below shows how this phase was built step by step, following the approach outlined above.
What I learned?
- Visual documentation isn’t enough for AI. Purpose, usage, constraints, differentiation and exceptions need to be explicit because AI cannot reliably infer them from the component alone.
- Decision logic matters more than exhaustive documentation. The goal is not to document every detail, but to capture the decisions a designer would normally make through contextual judgment.
- Documentation can become a cognitive and time burden. Defining every component individually wasn’t sustainable, which led me to create a Component Definition Matrix as a reusable knowledge structure.
- The designer’s role starts shifting from documenting to defining knowledge. I define intent, rules and boundaries; AI can then structure, document and build from those decisions.
Part 3 — Testing AI consumption
In order to check whether Claude could consume the system and make the same design decisions I would, I used Claim summary page (from the same old project).
Instead of giving Claude instructions for individual components, I asked it to recreate the reference UI using only the existing design system — no new tokens, components or styles. This shifted the test from “Can AI create this screen?” to “Can AI use the system to create this screen?”
Where it worked?
- ✅ Existing tokens were reused — Claude correctly picked up typography, colour, spacing and other foundation tokens.
- ✅ Defined components were reused — buttons, tabs, badges and other available components were consumed rather than recreated from scratch.
- ✅ The test exposed system gaps — these deviations became useful signals for identifying where the design system needed stronger definitions, additional variants or new components.
Where it failed?
- ❌ An existing component was used with the wrong variant — Claude recognized the component but selected a different variant from the one defined or required by the reference.
- ❌ Missing components led to improvisation — the Accordion pattern wasn’t defined in the system, so Claude approximated it using available components.
- ❌ Component rules weren’t always followed — the Label & Value Field was defined with a vertical orientation, while the reference required a horizontal arrangement.
- ❌ AI interpreted gaps instead of recognizing them as gaps — when the system didn’t provide enough direction, Claude made its own design decision rather than necessarily flagging the ambiguity.
What I took away from this experiment?
This POC didn’t prove that AI can replace the traditional design-system process. AI can become another way of building and consuming a design system — but only when the decisions behind the system are made clear enough for AI to understand. Below are some of the most important findings
AI can build design systems, but it still needs human direction.
I was able to use Claude Design to create foundations, components and documentation, while ChatGPT helped me reason through decisions and structure prompts. This reasoning matters.
The biggest shift is making design decisions explicit.
In a traditional Figma system, designers can often infer intent from the visual system and make contextual exceptions. AI needs more of that intent to be stated.
Tokens were relatively simple; components were harder.
The Primitive → Semantic model worked well, but components needed much more context around purpose, usage, variants, states and rules.
More documentation isn’t the answer.
The experiment showed that documenting every possible detail creates unnecessary effort. What matters is documenting the decisions AI cannot reliably infer.
The designer’s role changes, rather than disappears.
Instead of manually defining and documenting everything, the designer increasingly focuses on intent, decisions, rules and boundaries, while AI can help structure, build and consume them.
AI can also help expose weaknesses in the design system
When Claude chose the wrong variant, improvised a missing component or interpreted a rule differently, it revealed gaps in the system that may not have been obvious to a designer.
AI consumption is the real test.
A design system isn’t successful just because it looks complete. The stronger test is whether AI can use it correctly without repeatedly being told which component, variant or rule to follow.
Will I use AI-native design systems in projects?
Yes, but not for everything.
If speed and scale are the priority—especially when the design system is closely tied to development—an AI-assisted approach makes a lot of sense. But when the work needs precise visual control or a larger brand story, I’d still reach for a Figma-like environment.
For me, the ideal future is not AI vs. Figma, but AI + Figma—with a bridge that lets me move between speed and precision without maintaining two separate systems.
Prototyping at Speed with AI
If you enjoyed reading this POC, take a look at how I used AI to prototype a real product faster, from idea to working experience.
This is an access-restricted case study, so if you’d like to see it, reach out to me for access.