SuppCo · A closer look
Agentic Design System
A design system that people and coding agents can both follow
I made Capsule, SuppCo’s design system, AI-native, so designers, engineers, PMs and coding agents could all build on-system work from one source of truth.
- My role
- Head of Product Design, and the system’s hands-on owner
- Worked with
- Front-end engineering, product and our CEO, on a design team of two: me and the product designer I managed
- What I did
- Brought Figma and code into parity, wrote the decisions down as skills, and put the system where the work happens
I raised Figma-to-code token parity from 50% to 97% in eight weeks, and packaged the system as agent skills in its own repo, which engineers and coding agents built from, at a company where coding agents wrote a large share of the code.
The situation
AI made output cheap and judgment scarce. At SuppCo, PMs and engineers were already doing design-shaped work with AI: spinning up prototypes, generating screens from tickets, building their own decks and dashboards. None of that was going to slow down because a designer asked nicely.
Meanwhile, Figma and code had grown up separately: similar components under different names, and no agreed rules for when to use what. My favorite example: our Figma library had a “gray-lightest” and our codebase had a “seasalt.” Nearly the same color, two names, and I couldn’t tell you which gray was the gray. Following the system was a matter of persuasion, one person at a time, and most of that persuasion ran through me.
So the question changed. Not “how do we get people to follow the docs?” but “how do we make the right decision the easiest one to make, for people and for agents?” We didn’t have a documentation problem. We had a distribution problem.
My role
As Head of Product Design, I was a player-coach on a design team of two: me and the product designer I managed. I owned the system hands-on, from reconciling Figma with what was actually in production to writing the skills, and I made the case to front-end engineering and our CEO for where the system should live.
How I approached it
- 01ParityFigma and code tell the same story.
- 02CaptureDecisions written down as rules anyone, or any agent, can check.
- 03DistributeThe system lives where people and agents already work.
- 04CompoundOn-system work from people who never asked a designer.
-
Get to parity first
Figma was behind code, so the first job was catching it up. Reconciling color and type gave us a code-accurate Figma library, and with tokens in place, redrawing our components to match code and Storybook was straightforward. It’s the unglamorous part, and it’s where governance becomes enforceable: you can’t write a rule about which gray to use until there’s one set of facts about what the grays are.
-
Write decisions down as skills
Next, I wrote decisions down as skills: when to use what, which type style goes on a screen title, and what to do when the system disagrees with itself. The trick that made them work was keeping every rule binary and checkable. “Use the right type size” isn’t a rule; “screen titles use this style, never a raw font size” is. That gave people a contribution model to build against instead of asking me, and once the skills reached Claude and Devin, our coding agent, the decisions stuck for people who aren’t designers.
-
Put the system where the work happens
This is where the most important conversation happened. Front-end engineering wanted the web app’s code to be the source of truth, a reasonable instinct. I argued that the system had to be global and agent-permeable, supporting every artifact the company makes, not just the app. We landed on a trade: web tokens define Figma, and in exchange the system gets a third place any agent can reach, a design system repo holding the token JSON alongside the skills.
Parity is what made that safe. It turned the repo into a design service layer that agents can read and people can query. Without it, an agent reading our tokens would have been reading two different stories.
-
Let it compound
Once the system lived where design-shaped work actually happens, the results compounded. Non-designers started producing on-system work, from town hall decks to dashboards and marketing pieces, with just the skills and no design oversight. Prototyping skills built on the repo produced repeatable, shippable prototypes with shareable links, and prompt-based workflows let us move in every direction: code to Figma, Figma to code, and on to decks and docs.
The same request, without and with the skills (dummy numbers).
What changed
The biggest shift wasn’t in the system. It was in where my time went. With the rules in the repo and the agents following them, I stopped being the bottleneck for “is this on-brand?”, and that time went back to the work only a designer can do: deciding what the rules should be, noticing where the system is wrong, and making the calls that don’t fit into a skill yet.
What I learned
- Get to parity first. Agents amplify whatever is in the source.
- Put the system where the work happens.
- Measure who ships on-system without you.
AI is great at the first draft and the hundredth repetition. It isn’t great at taste. An agentic design system is a way of writing your taste down clearly enough that it travels without you. Judgment is the job; the system is how it scales.