Case StudyFanDuel
The system
becomes shared
AI infrastructure
- Design systems
- AI integration
- Platform strategy
- Cross-functional leadership
- Company
- FanDuel
- Role
- Lead Designer · IC / Manager Hybrid
- Scope
- Proof of concept, cross-functional validation
- Duration
- 2026 - Present
The work
Proving the
system as AI
infrastructure
AI agents were already building with the design system, before anyone had decided what good looks like.
Teams were prompting Cursor, Claude, and prototyping tools directly, and none of that consumption ran through any governed source. I wanted to know if that was actually a problem, or just a new way of working we hadn't caught up to describing yet.
I ran a proof of concept to understand if a unified governed source of truth could measurably change what these agents produced, without changing how designers or engineers already worked.
- Baseline pass rate, ungoverned
- 0%
- Pass rate with governed schema
- 87%
- Components schema-validated
- 4
- Cheaper per correct output
- 11x
The problem
AI output is only as good as what it's given
AI amplifies the system's foundations. When sources disagree or a fact is missing, the agent fills the gap with a guess.
Tools scraped Figma, parsed docs and read component code, then stitched together an answer. The output carried the system's look and none of its accountability.
I started with a controlled test: three agents, three ways of consuming context, one task, rebuild the same component. All three looked acceptable at a glance. None got the typography right. Some invented tokens outright. The failures were systematic, not random.
The vision
From “AI guesses our design system”
to live, verified, self-updating truth
A single governed source of truth can measurably reduce output that carries the system's look but none of its accountability. Foundations, guidelines, components and tokens sit behind one entry point. The agent reads from it, and what comes out is reliable and predictable because what went in was.
The question was not whether AI could use a design system. It clearly already was. It was whether a governed, machine-readable source could close the quality gap, without changing how designers or engineers already worked.
A well-structured design system doesn't get forced into AI workflows. It gets pulled in.
The approach
A big bet,
with a narrow scope
The question was never whether AI could use a design system, it clearly already was. It was whether a governed, machine-readable source could close the quality gap without changing how anyone already worked.
I didn't have a team or a budget for this, so I made it deliberately narrow. One component, complex enough to stress every part of the schema, multiple variants, token references, accessibility rules. If it couldn't hold there, nothing after it was worth testing.
I owned the information layer myself and delegated the MCP distribution and connector work to a teammate who's stronger there. That split mattered, it let me focus on the part that actually determines output quality, not the plumbing.
- 01
Prove the case
One component complex enough to exercise the full schema: multiple variants, token references, accessibility rules. If it couldn't hold here, nothing else was worth testing.
Mine - 02
Harden against variation
Three more components followed, each with a different content shape and token structure. Every failure became the next version. Four components validated clean, with zero changes upstream.
Mine - 03
Govern and distribute
I took care of the information layer: the schema, the per-component data files, the documentation and the translation logic. The distribution layer and the MCP connection were built by a collaborator.
Information layer: mineDistribution + MCP: collaborator - 04
Validate externally
I brought in a reviewer outside the work, feeding the schema to an external AI agent and auditing what came back. That audit found real gaps my own checks had missed.
Outside reviewer
01 / The first run
Wrong direction,
not wrong system
The first end-to-end test was asking an agent to find a component, pull its data, rebuild it as code. The gap wasn't in what the system could catch. It was in where the system was actually looking.
01 What shipped
Every value came back correct, straight from the real token file. Everything else was invented: a hand-rolled div, Unicode instead of real icons, and made-up variable names.
02 What I caught
Nothing in the pipeline flagged it. I asked the agent directly whether it had used the real icons or invented anything, and that surfaced every gap. My checks existed, just scoped to a different folder. The only thing that fired was a person asking.
03 What I changed
I turned the manual catch into a standing report, checking every rendered part of a component against the real package and tokens, automatically. The next version doesn't depend on me remembering to ask.
02 / The fix
Right answer,
wrong question
This wasn't a wrong answer. It was the right answer to a question the schema never asked.
01 A new kind of gap
A collaborator building a real component off the schema hit a render with a filled circle behind the icon. Every value was correct, real colours, real tokens, nothing invented. The shape was still wrong, and none of my checks caught it.
02 What the audit found
The circle didn't exist in the real component, and neither did several other details. All of it traced to one gap in the data: nothing said whether a container was visual or just structural scaffolding. My checks missed it because every value used was still a legitimate design-system token.
03 What I added
A field to say, explicitly, whether a piece of anatomy is structural or visual. That one addition closed the gap, and gave any future check, mine or anyone else's, the one signal it had been missing.
The cost curve
The set-up cost
is sub-linear
Getting the schema to produce the first component output right took days. Every one after that took minutes, because the failures from the first became rules in the schema, so the second, third and fourth inherited that hardening for free.
Once a pattern is resolved in the schema, all components sharing it become near-free. The ingest pipeline and schema pattern consolidation compound across the library.
That's the actual argument for scaling this past a proof of concept. Full component coverage is a sprint's worth of work, not a multi-quarter program, if it gets resourced properly.
The product application
Turning the “invisible work”
into visible products
None of the schema work is visible to anyone outside the system. So in parallel, we built the same governed data into UI kits in Figma Make and Lovable, so people could prototype against the real system, real tokens, real theming, without needing me in the room. Not shippable product, but it took the friction out of getting an idea in front of someone fast.
The schema and constraints do the magic behind the scenes. The visible work is a kit that lets someone else make the product decision, fast, inside the system's rules.
Reflections
Proven, not
shipped. Yet.
The proof of concept settled the technical question: a governed source measurably reduces rework costs and AI-generated errors.
The MCP layer with governed data hasn't shipped, and the reason isn't technical. The design system team lost its dedicated engineering capacity in a reorganisation. The capability to build this now sits with teams reporting into different leadership, each delivering exactly what their own leadership asked for.
Nobody's failing at their job. There's just no shared priority spanning the two chains, so work that would take a week gets negotiated for a quarter.
My move now isn't to keep pushing the technical case, that part's proven. It's naming the decision explicitly, so it becomes something the organisation can choose to resolve.
Learnings
- 01
The bottleneck is content, not architecture
The schema absorbed every component without a structural change. Scaling this is a documentation-consistency problem, not a schema problem.
- 02
A schema is a hallucination guardrail
Not just a structure. Every field's source gets verified, so missing data gets flagged at build time instead of invented at runtime.
- 03
Smarter models are not the fix
A more capable agent with no governed source doesn't get more careful, it produces wrong-but-confident output faster.
- 04
The cost curve favours starting narrow
Proving one component properly before generalising meant the failures were real, not hypothetical, and each made the next component cheaper.
Let's
talk
Open to conversations about design systems, product craft, and what good design infrastructure looks like in practice. If you're building something great and thinking about how it scales, let's talk about it.