Skip to content
Chris Dunn · Experienced Product Designer
← All work

Purple Design: Building an agentic design system

Everything used to be designed in Figma, then rebuilt from scratch in code. I built an agentic design system, so whoever is building now works straight from the source. Point Claude at our MCP and it builds with the real components.

At a glance

to a prototype, down from weeks
Hours
successful MCP calls in the first month
2,000+
components, over 13 foundations and 10 patterns
70
tools exposed to AI clients, across three servers
48
The Purple Design documentation app, open on the desktop overview
My role
VP Design at Purple. I designed and built the system myself
Footprint
70 web components, 10 mobile-native
Who uses it
Product, marketing, customer service and design

The problem

Our designs and our prototypes were both made in Figma. Developers got them as walkthroughs and schematics, read the file, inspected the components and built from that. A basic prototype could take months.

It always came back slightly different. A developer is not reading a layout for the same details a designer is.

We did have a design system, but it lived in Figma, and the build happened in code.

Then everyone started prototyping

AI changed who makes prototypes. Product managers, marketing, customer service reps: people across the business started building interfaces, and all we could give them was the Figma library. Their tools read it however they liked.

What came back had the right colours, the right fonts, and components we had never made. Every prototype was a fresh interpretation, so no two matched. They all arrived at the design team for review, and we could lose days in a week to it.

What an AI agent is given to build from, before and after Purple Design
What is being comparedThe Figma systemPurple Design
What the agent readsA screenshotThe real packages, from GitHub
What decides the layoutThe agentTemplates, and the rules in the manifest
Checked afterwardsNoEvery build
What comes outInconsistent UI, every timeThe right components, used the right way

A site that documents itself

The documentation is a by-product of the build. Building the top navigation produced a top navigation component. Defining the type and the colour produced the foundations. Adding tiles, metrics and tools produced more components.

It sorts into three tiers. Foundations are colour, typography, spacing, elevation, motion, icons, illustrations and the tokens. Components are the pieces: buttons, app bars, cards, fields, modals, line charts, 70 in all. Patterns bring those together into something whole, like a calendar or a sign-in page. Desktop came first, mobile followed.

I wanted full control over the system: a website that documents itself, which I could then expose to AI agents.

The library

Every foundation, component and pattern gets its own page, and showing the thing is not enough. The button page is a playground: every variant, every size, loading, disabled, with an icon and without. Beside it sits the code you would write, the props, an automated accessibility pass documented against WCAG 2.2, and guidelines for where the button belongs and where it does not. Then a link to the package, so you can go and use it.

The Button page in Purple Design, with its live controls and the source file it is generated from
Five variants, three sizes, and the file they come from, on the page itself.

Tokens

One token package feeds everything. Colour, type, spacing and motion are defined once, and nothing downstream keeps its own copy, so there is no second version to drift from. When an agent builds a screen it inherits the real values rather than picking something close.

Templates

A correct component in the wrong place still makes a screen that is not ours. Templates are collections of components and patterns with rules about arrangement: an app shell is a left side navigation, a top navigation and a main container. There are dashboards, table views and settings pages too, around ten in all.

A Purple Design template in scaffold view, every region outlined and labelled
Scaffold view names each region after the component that renders it.

Putting it behind an MCP

The system is exposed as a URL. Add it as a connector in Claude Code and ask for what you want: build me a dashboard using the Purple Design System.

It fetches the real packages from GitHub and builds from those. Ask for a template and it uses that one; otherwise the templates decide where the components go. Rules in the manifest, a generated JSON file nobody edits by hand, say where a side navigation lives and where a top navigation lives. When the build finishes, the MCP runs the validation and checks its own work.

Claude Desktop calling the Purple Design MCP tools, with the system's orientation returned as the first response
The tools load, and the system answers with its own orientation before anything gets written.

What it has done so far

More than 2,000 successful calls in the first month. The days a week we lost to reviewing other people's prototypes came back.

The design team governs the look without making the prototypes, which matters when most of the people making them sit in other teams. If someone needs a component that does not exist, I build it, push it to the packages, and they have it.

Work that ran to months on a large project and weeks on a small one now takes hours.

What I learned

Live packages are the whole thing, not a detail. The first version of the MCP built from an imprint of the system instead. It followed every rule, it looked right, and it was frozen. Anything made that way would have fallen behind the moment the system moved on, and nothing in the output would have shown it.

The packages now check for a newer version on every build. The snapshot route is still there for anyone who cannot connect, and a handful of people still take it, which is the original problem in miniature. The system is also only weeks old, so the numbers are early and nothing has been through a full product cycle yet.