The best design system is one you stop thinking about. Here's how we used AI to get there.

Summary

Maybe we got lost in translation,
maybe I asked for too much
- Taylor Swift, All Too Well

The harder a system is to understand, the narrower the group of people who can use it correctly.

This is how we used AI to finally get out of everyone's way — and let the people closest to the problem focus on solving it.

Role

Lead product designer, AI-native designer, systems thinker

Team

Target Design Systems

Timeline

2024 — present

Problem

A design system should be invisible. Ours wasn't.

Consuming designers were spending more time learning the system than using it

How a component flexes, what's intentional vs. cosmetic, when to reach for which pattern — none of that was easy to find. Designers were doing archaeology before they could do design.

We were maintaining two libraries that were never quite the same

One in Figma. One in code. They told the same story differently, and the delta between them never fully closed. When you have two versions of anything, you will always have room for error.

The system kept getting in the way of the work it was supposed to support

Both problems have the same root. The system was meant to be load-bearing infrastructure — invisible, reliable, out of the way. Instead it was something everyone had to fight through to get to the actual work.

Phases

Readable. Generative. Participatory.

1 Readable

The system's knowledge was locked away from the people who needed it most. So I built a way for anyone to ask it questions directly — and get back to designing faster.

2 Generative

Generative tools were designing fast but off-system. So I encoded our system into markdown — now generation stays on the rails from the first prompt, and nobody has to correct it after the fact.

3 Participatory

The agents knew the system. I just had to know what I wanted to build. When the translation layer disappears, the system finally gets out of the way.

Phase 1: Making the system answerable

In the beginning, AI was synonymous with an LLM.

The first unlock was realizing we could use this new technology by loading our design system documentation into a custom GPT and letting anyone ask it questions directly.

My hypothesis: lower the barrier to understanding the system, and you raise the quality of everything built on top of it — and everyone gets more time back for the actual work.

1 Anyone can more easily understand how a piece of the system should work

2 What they hand off better matches how we designed and built it

3 The engineer picking it up lands closer to what we intended

Answering our users' questions directly was the first real step toward getting the system out of the way.

However, this was only mildly effective because it didn't fit in to their workflow. This still required users to have an internal motivation to use the system and ensure they were using it properly.

We needed to catch them before they even got there.

And then, a new problem emerged.

Phase 2: Designers generating UI

The tools stopped only answering and started designing.

Claude Design

Figma Make

Google Stitch

This sped up a designer's workflow tenfold — in theory.

But what they were generating was agnostic of any system. Speed without fluency made the system more invisible in the wrong way — the constraints disappeared, not the friction.

Any inconsistency in how someone understood the system was now being amplified, at the speed of a prompt.

And here's the thing, a flashy, working prototype is easy to fall for.

So stakeholders were buying in to ideas before it touched the system.

And then the thing they approved changed drastically once it had to "get translated" into our system.

If AI was going to design, it had to design on-system from the start, not get corrected after decisions were already made.

We quickly realized we needed to give the machine a way to read the system the way a fluent designer would — so it could stay on-system without anyone having to babysit it.

We converted our system into markdown — now the machine could read and interpret it as a designer would.

It worked. Generative tools were actually building with our system.

But even with a clearer way to communicate a vision, design intent was still getting lost in the handoff.

Phase 3: What if the system just got out of the way?

A new wave of tools were taking on the responsibility of having to know the system, so the user didn't have other.

Lovable

Claude Code

Codex by ChatGPT

Figma MCP

I built our agents to carry the system's knowledge so the system's constraints became the starting point for every build.

The agent already knew what the system was capable of. The builder just had to know what they wanted.

What Claude Code changed for me wasn't just capability — it was cognitive load.

I wasn't spending mental energy on how to implement a component or whether something was possible within the system. The guardrails were already built in. I was just designing.

That's when I understood what the system was really for. Not a reference doc. Not a constraint. A shared language that — once the machine could speak it — meant anyone could build with it. Technical fluency stopped being the cost of entry. For the first time, I wasn't thinking about the system at all. I was just building. That's when I knew we'd gotten somewhere real.

It worked! A real, on-system app, built start to finish by a designer.

Submit a request, upvote the ones you want, and finally see where your request went after you hit send.

Our first real proof that closing the gap completely isn't just a theory.

I took something real from our backlog to prove it.

I had time for the details that usually get lost

Motion, interaction, edge cases — the things hardest to convey in a handoff — were included from the beginning, because the person who cared about them was the one building them.

I could make better decisions when they were live and in real-time

This made the process of designing, shipping, testing, and iterating so much faster.

And I came away with a deeper understanding of what it's actually like to build with our system.

The gap between how I thought our components worked and how they actually behaved in code became very apparent — and illuminating.

Because when everyone is working directly from the same library, the design implementation and the coded implementation stop being two separate things. And when you have two of anything, you will always have room for error.

One source. One set of pieces. The system finally gets out of the way — and everyone gets back to the work that actually matters.

Where this goes

It's not just me thinking like this. Teams like Gusto are already there.

Amy Thibodeau, Gusto's Chief Design Officer, has described designers shipping fixes directly — without waiting on an engineer's backlog. This isn't a fringe experiment anymore. It's a direction.

The system was always meant to be invisible. AI is finally making that true.

When a design system becomes truly shared infrastructure — readable, generative, participatory — the lines between who can contribute start to blur.

Not because roles disappear, but because the barrier to using the system fluently gets low enough that anyone can clear it.

The best version of this doesn't mean fewer people. It means less lost between them — and more time for the work that actually matters.

I don't have the whole answer yet, and I'm still asking questions every day.

1 What does it mean to own a system when anyone can participate in it?

2 How do you build fluency in a system without requiring technical depth?

3 What does a contributor role look like when the tools do the translation?

No longer lost in translation. Finally free to do the work that actually matters.