Making Design Systems Legible to AI

Detailed UI masked per NDA. Process artifacts and metrics shared with permission.

Summary

• Problem. Most teams were adopting AI by pointing it at whatever step already felt slow, treating it as a plug-in for the existing process instead of asking what AI actually needs from a team to produce something reliable.
• Role. I owned the design-phase mechanism (Figma Make, prompt structure, guideline authoring), the token discipline that made the handoff work, and the review process that decided what shipped.
• Impact. 80% of WorkFeed's components converted correctly with little to no manual fixing. The 20% that didn't pointed to a specific, fixable cause: component granularity, not model capability.
• Stack. Figma Make · Figma Code Connect · Figma MCP server · GitHub Copilot (VS Code) · Claude · Style Dictionary

The premise

AI can generate a design or a component fast. Whether it generates something usable fast depends almost entirely on what you give it to work with. A design system built for humans, consistent components, named variants, clear rules, turns out to be exactly what a model needs too. An inconsistent one doesn't get fixed by AI. It gets guessed at, faster.

Most teams at the firm were approaching AI adoption by looking for a slow step and pointing a model at it. That's a reasonable starting instinct, but it treats AI as a plug-in for the existing process rather than asking a more basic question: what does AI actually need from us to produce something reliable? We asked the second question. Blueprint, the design system I'd been building, turned out to already have most of the answer, because the same discipline that makes a system good for a human developer, no raw values, clear component boundaries, documented intent, makes it legible to a model too. I hadn't built it with AI in mind. It became AI-ready as a byproduct of being built well.

What we changed

The rule that mattered most: nothing in a finished design ships with a raw color or spacing value. Every choice ties back to a token, component-level first, semantic as a fallback, nothing hardcoded. That discipline was already how I ran Blueprint. What changed is that it turned this system into something a coding assistant could actually read, instead of something it had to guess at from a picture.

Behind that rule sits a small set of structured files: separate files for the raw values, the semantic layer that gives them meaning, and the component tokens built on top of those. A markdown file explains how the three layers connect. Each component has its own file describing when to use which variant, written the way you'd brief a new engineer joining the team. Style Dictionary generates all of this from the source definitions, so none of it is duplicate, hand-maintained work.

On the code side, Figma's Code Connect maps each design component to its real counterpart in the codebase. The Figma MCP server exposes that mapping, along with the token values and component structure, as information a coding assistant can read directly. We ran this through GitHub Copilot inside VS Code, with Claude writing the actual code. Worth being precise about what that bridge does: it doesn't generate anything itself. It hands the model a well-organized starting point instead of a screenshot to guess from. The generation still comes from the model.

The workflow

Four stages, each with a different job for AI and a different job for a person.

Design

A finished layout, built entirely from Blueprint components, already carries everything the next stage needs, because nothing in it is a one-off value.

Structured handoff

The token files and Code Connect mappings turn that Figma file into a real starting point in code, not just a picture for an engineer to interpret.

Generation

Copilot and Claude produce working code from that structured input.

Review

Every generated component gets checked against what Blueprint actually defines before anything ships. This is the stage that decides whether the first three stages were worth the setup.

This system also grew out of earlier, separate experimentation. Before design-to-code became the focus, we tested whether AI could help even earlier, in live client work, generating rough prototypes during strategy conversations instead of spending hours on wireframes between meetings. It worked for what it was: decisions moved faster, exploration got cheaper. But the output stayed rough, not something you'd hand a client as finished work, and a designer still made every real call. That early test is part of why we trusted the bigger bet on design-to-code. It's not the main story here. WorkFeed is.

WorkFeed

WorkFeed, a task management proof of concept inside the Hub platform, is where this pipeline actually ran, under a real deadline, in front of someone who could greenlight it beyond a prototype.

What we expected

That a well-structured design, built entirely from system components, would generate mostly correct code, because there'd be nothing left for the model to guess at.

What happened

Going through the output component by component against what Blueprint defines, about 80% came out right, with little to no manual fixing needed.

Where it broke

The 80% clustered almost entirely around simple, single-purpose components, buttons, list items, anything with a small, well-defined set of states. Composite components, ones built from several smaller pieces stitched together, didn't convert cleanly. A task card combining multiple nested elements needed real manual rework.

Why it broke

This wasn't random. It matched a finding our frontend engineer reached independently, from the code side: components need to be broken into their smallest logical pieces before they're mapped to code, not after. A combo box shouldn't be one file. The input and the dropdown list need to be separate, independently mapped pieces from the start. Skip that and you get exactly the mismatch we saw.

Two people, coming at the same problem from opposite ends, landing on the same root cause. That convergence is better evidence the underlying idea holds than the 80% number is by itself. It also gave Blueprint's existing component-review process a clear new question to ask of every new component: is this granular enough for a model to map cleanly, not just clear enough for a designer to use.

• 80%

  Components converted correctly against the Blueprint spec, with little to no manual fixing. See the Blueprint Design System case study for the token architecture and Code Connect setup behind this.

What worked, in three sentences

Design exploration got faster, because AI could produce several directions in parallel instead of one at a time. Design-to-code got more predictable, because the model was working from structured tokens and mappings instead of inferring from a screenshot. And the failure pattern taught us something specific and useful: component granularity, not model capability, was the actual ceiling.

On cost, honestly

I'm not going to give you a time-saved or cost-saved number. Not because it wasn't worth asking, but because a fixed figure in this space goes stale fast, both what these models cost and what they can do are moving quickly enough that a specific number from late 2025 won't mean much by the time anyone reads this. The more useful question, and the one we were actually trying to answer, isn't what this saved once. It's whether a team has a real way to keep judging if the investment is still worth making as the ground shifts under it. That's a harder answer to give than a percentage. It's also the honest one.

Where this leaves the system

Blueprint already had a working process for deciding what gets built into it: who reviews a request, how it gets scoped, what happens when the answer is no. WorkFeed adds a clear argument for extending that process, scoping every new component for how well a model can parse it, not just how well a person can use it, at design time, before it ever reaches a code-gen pipeline. I wasn't at the org long enough to see whether that became a formal part of the process, so I can't claim that it did. But the case for it is sitting right there in the 80/20 result.

What I'd carry forward

We built this against a real deadline, in front of someone who could take it straight to production. That mattered more than it sounds like it should. If the proof of concept worked, there was a real risk it would get pulled out of our hands before it was actually ready to be a shippable feature. So the goal on the design side was never to make something that looked impressive. It was to make sure that if this did take off, what we handed over could still function as a real first version, not a demo that fell apart the moment someone tried to build on it.

That pressure shaped the harder calls more than anything else. When two directions don't clearly differ in impact, and you don't have enough information yet to know which one's right, you're working from your best judgment, not certainty. That's true of design generally, not a flaw specific to this project. We made real decisions under that uncertainty, and we changed direction quickly more than once when something new came up. I don't see that as a weakness in the process. I see it as what the process is for.

The idea that actually holds this whole project together didn't arrive as a plan. It came together in pieces, watching what other design system teams were doing, a deadline that forced real scope discipline, and a reframing I picked up secondhand that happened to land at the right time. Every piece, arrived at separately, kept pointing at the same underlying fact: a design system built with real discipline doesn't just serve designers and engineers anymore. It's also what makes AI worth using at all. Design systems aren't becoming less important because AI can generate interfaces. They're becoming the thing that decides whether AI-generated interfaces are any good.