AI-Ready UI Infrastructure
How I turned Sinatra's Figma design system into machine-readable infrastructure for Claude so that AI could generate the interfaces, engineering could ship them, and the design role could shift from operating Figma to owning product decisions. A move into product ownership.
- Role
- Product Designer / Manager
- Team
- Product · Engineering
- Timeline
- 8 Weeks
- Platform
- Figma · Claude
- 100%
- Of execution work (UI assembly, prototyping, deck building) handed off to AI-driven generation
- 3x
- Faster from product idea to high-fidelity interface using real components and tokens
- 100%
- On-brand output — generated UI, decks, and proposals built from the actual system, not generic lookalikes
The most valuable person in the room was assembling screens.
At Sinatra I joined as founding designer right before the pre-seed round. Early on, the job was everything: research, Information Achitecture, interaction, UI, prototypes, design system, even pitch decks and commercial proposals.
As the company raised its seed and the product surface grew, a problem became impossible to ignore: I was spending most of my time on execution, not on decisions.
Wireframing. Pushing pixels. Rebuilding the same patterns. Assembling decks. The work that actually moved the business (what we build next, why, for whom, and what it's worth) kept getting squeezed into whatever was left.
The market was commoditizing execution, AI could generate interfaces and we was using tools like Lovable and Replit already but it generated generic interfaces. It wasn't an AI capability gap. The gap was infrastructure for UI generation.
There was an obvious objection to spending weeks on this: we were a lean, post-seed team with a roadmap full of customer-facing features. Time on internal infrastructure is time not shipping product.
I made the opposite bet. Every week I stayed in assembly mode was a week the product had no one fully focused on what to build and why. My time allocation was the constraint. Automating execution wasn't a detour from the roadmap; it was the thing that would let the roadmap have an owner.
I'd already built Sinatra's design system from scratch: components, semantic naming, documentation. It was solid, but it lived as a human artifact — readable by designers, invisible to machines. If a machine could read it as precisely as my team did, execution could be delegated, and the role could move from operating Figma to owning product.
Execution was the bottleneck
The highest-leverage person on product was spending hours on assembly work.
AI output was off-brand
Generated UI ignored real components and tokens. Fast, but unusable without a full rebuild.
Product Strategy had no room
Roadmap, prioritization, and business framing competed with pixel work and usually lost.
What does a machine actually need to "see" a design system?
Before building anything, I treated this like a product discovery problem, not a tooling experiment. The user was AI. The job-to-be-done: generate product UI, decks, and proposals indistinguishable from work made inside the real system.
I worked backward from the failure modes of generic AI generation and mapped what was missing at each layer.
A source it could read
The system lived inside Figma, readable by designers but not exposed in any way a model could consume directly.
Examples it could learn from
Named components weren't enough. Claude needed to see real, shipped interfaces to learn what "on-brand and correct" actually looks like.
Rules it could obey
Brand, tone of voice, usage guidelines — all in human prose and tribal knowledge. Nothing a model could follow deterministically.
Insights
A design system is a contract, not a library. The value isn't the components — it's the shared agreement about how things are named, structured, and combined. AI just needs that contract in a format it can parse.
Off-brand AI output is a data problem, not a model problem. The model was capable. It simply had no access to the source of truth. Fix the input, fix the output.
How I scoped the bet.
Before touching the architecture, I had to define what success looked like and what would make this worth pulling time away from the roadmap. I scoped it around three questions and one hard rule.
How might we make the design system machine-readable without maintaining two parallel sources of truth?
How might we let AI generate UI, decks, and proposals that are on-brand by default — not after a rebuild?
How might we redefine the design role so execution is delegated and product decisions become the center of the job?
How I'd know it was worth it
I set a simple bar up front: this only pays off if generated output ships to production with engineering's normal review — no designer auditing every pixel. If it needed a full manual rebuild each time, the bottleneck would just move, not disappear. That bar is what told me when to stop building infrastructure and start spending the reclaimed time on product.
Constraints that shaped the solution
- One source of truth, or it dies. Any system that required maintaining a separate AI copy would rot in a week. Everything had to flow from the existing Figma system.
- Lean team, no design-ops hire. The infrastructure had to be set up once and run with near-zero maintenance — or it wasn't worth the roadmap trade-off.
- Output had to be trusted at the team level. Product and sales needed to generate on-brand work themselves, not route every request back through me.
A design system Claude can read and build production UI from.
I set up the foundation in Figma — a clean component library with semantic naming, tokens, and variables structured to the W3C DTCG standard. Then I fed Claude that same system through three channels at once: the Figma MCP for the live source, our design system repository on GitHub, and .fig files of our real, shipped interfaces as examples. Finally, I wrote the SKILL.md / CLAUDE.md encoding brand, tone of voice, and usage rules.
With that in place, Claude Design generates interfaces, decks, and proposals on-brand by default. I refine them, then hand off to Claude Code — where the front-end team validates everything and ships to production. The design system stopped being a static library and became the contract that product, AI, and engineering all build against.
What feeds Claude
| Input | What it gives the AI |
|---|---|
| Figma library (DTCG) | Components, tokens, and variables with semantic naming — the live source of truth. |
| Figma MCP | Direct read access to the design source — structure, components, and intent. |
| GitHub DS repository | The coded reality of the system, so generation aligns with what's actually built. |
| Real .fig examples | Shipped interfaces as reference — what "on-brand and correct" actually looks like. |
| SKILL.md / CLAUDE.md | Brand, tone of voice, and usage rules as instructions Claude follows deterministically. |
Why this was a product decision, not a design task
Choosing to automate my own execution was a bet on where leverage lives — a call about how the team's scarcest resource gets spent, not a styling choice. The technical setup was the easy part; deciding it was worth doing was the product call.
Why engineering still owns the last mile
Generated and refined UI goes to Claude Code for the front-end team to validate before production. AI moved the execution work; engineering still owns the bar for what ships. The point was never to remove people — it was to move them up the stack.
Why the scope went beyond product UI
The same infrastructure generates on-brand sales decks, commercial proposals, and campaign images. Once the system was readable, the leverage wasn't limited to product screens — it became company-wide design infrastructure.
Why semantic naming was non-negotiable
Without semantic tokens and component names, the model has nothing to anchor to. Naming is the API of a design system — and the API is what makes it machine-readable.
From operating Figma to owning product.
- Most of my time spent on UI assembly, prototyping, and deck building
- AI generation existed but produced off-brand, unusable output
- Product decisions competed with execution — and lost
- Design system was a human-only artifact, invisible to machines
- 100% of execution work delegated to AI-driven generation
- 3x faster from idea to high-fidelity, on-brand interface — anyone on the team, not just me
- Product and sales generate on-brand decks and proposals without routing through design
- A reclaimed week that went into discovery, prioritization, and business framing instead of pixels
“The bar went up, but the door didn't close. Execution is being commoditized so I moved up to where the leverage is: deciding what to build and why.”
What this project leaves behind.
Automating your own execution is a product strategy
The highest-leverage move wasn't designing a feature — it was redefining how the design role allocates its own time. That's product thinking applied to the role itself.
A design system's real value is as a contract
The components are the surface. The shared, machine-readable agreement underneath is what lets product, engineering, and AI move in sync.
On-brand AI is an infrastructure problem
Better prompts don't fix off-brand output. A pipeline that feeds the real source of truth does.
The role moves up the stack, not out the door
When execution is delegated, the design role doesn't disappear — it absorbs the product decisions execution used to crowd out. That's the transition this project made real.