The AI Design System Workflow That Stopped Giving Me Slop

AI design slop is not a model problem. It is a training-data problem, and it is fixable in an afternoon. When Claude generates a screen that is almost your design system, arbitrary corner radii, a gradient you never defined, the wrong 16px, it is doing exactly what a model does with unlabeled data: averaging your system against every other interface it has ever seen. The fix is not a better prompt. The fix is making your design system legible to a language model: tokens with when-to-use sentences, components grouped with usage rules, concrete reference screens, and iterating locally as HTML before a single frame touches Figma.

I run design work across four brands (mejba.me, Ramlit, ColorPark, xCyberSecurity), and multi-brand work is where slop compounds fastest, because every unsystematic generation drifts each brand a little closer to the same generic average. What follows is the workflow that stopped that, including the before-and-after from rebuilding my own blog's design system this summer.

Why "Just Point Claude at the Figma File" Fails

The failure mode is precise. You connect the Figma MCP server, prompt "generate a settings screen using our design system," and get output that technically uses your components without understanding when to use them. The hierarchy feels off. The card shadow is close but not yours.

The reason is obvious once named: a design system file is a warehouse, not training data. Tokens sit in one collection, components in another, and the actual knowledge, "elevated surface for floating UI only, raised for cards," lives in a senior designer's head or an unread Notion doc. Claude reads names and values; it does not read intent. Every ambiguous decision gets resolved by statistical averaging, which is how your paywall ends up vaguely Stripe, vaguely Linear, and not at all yours.

Figma's own MCP documentation points the same direction: the server ships foundational skills like figma-use, and its custom skills guide exists precisely because you are expected to layer your domain knowledge on top. Most people skip that layer, then blame the model.

I know what the unsystematic "before" state looks like in unforgiving detail, because I audited my own site before the redesign. The blog templates had 90 hard-coded text-white instances, zero semantic tokens on the page shells, and five templates each redefining the same styles under five different prefixes. No model could generate on-system screens against that, because there was no system to be on. There was only precedent, and precedent is exactly what models average.

Tokens That Talk: Give Every Value a When-to-Use Sentence

The single biggest unlock is embarrassingly simple. Claude is a language model; your tokens are hex codes. Non-linguistic input forces inference, linguistic input gets followed. So make the tokens speak.

Here is a slice of the real semantic ramp that now drives my blog, as it exists in my Tailwind config, with the usage sentences I feed to Claude:

Two details in that ramp carry a lesson each. First, every token maps to a CSS custom property with light and dark values, so one class themes both modes and the model never writes a dark: variant by hand. Second, some entries are deliberately aliases, not tokens: the focus ring is defined as always the link color, and chip text as always body ink, so they cannot drift apart. Writing "this is an alias, not a separate decision" into the system is precisely the kind of intent a model can follow and a hex list cannot express.

Do this for every category, including spacing. space-2: 8px, tight rhythm inside dense form groups is a different instruction than space-2: 8px. Save the whole thing as design-tokens.md in the repo, next to the code. That markdown file is now your real design system; the Figma variables are rendered output.

One caution from experience: do not assume Claude can just read your Figma variable descriptions. It can, but most teams' descriptions are empty or written for designers ("primary brand color") rather than for a model choosing between five blues. Rewrite them for the model. Designers can still read them; nobody loses.

Group Components So the Model Does Not Panic

Hand Claude 140 components in a flat list and it behaves like a contractor handed a hardware store and told to build a kitchen. Group them semantically, three groups cover most product UI:

1. Form elements — inputs, selects, toggles, date pickers, error and help text, with every state (default, focus, error, disabled, loading).
2. Navigation — top bars, side nav, tabs, breadcrumbs, pagination, steppers, with active and collapsed states.
3. Data display — tables, cards, list items, stat tiles, badges, empty states, skeletons. This group is where AI screens die, because the model defaults to a table when a card grid is right.

For each component, document three things: the variants with the exact key names from your Figma properties panel, the props, and one usage sentence: "Compact variant for dense tables over 8 columns; default otherwise." That sentence is what stops variant roulette. If you have multiple designers, argue the usage rules out loud before writing them; the argument is the spec, and the disagreements that surface are exactly the edge cases the model will otherwise guess. I first worked out this grouping pattern in my Claude Code and Figma MCP workflow, and it has survived every project since.

Show, Don't Describe: Reference Screens

"Build me a paywall" is vagueness masquerading as brevity. The prompt that works pairs your system with two or three reference screenshots of shipped production screens in the pattern you want, from a library like Mobbin (hundreds of thousands of screens from production apps) or from your own swipe file:

"Build a paywall screen for a finance app. Style and layout reference attached. Use our design tokens and components. Hero: annual plan at $79.99 with a 'Save 40%' pill. Three feature rows. Monthly toggle. Trust logos at bottom."

References for composition, specificity on content, constraints on the building blocks. Nothing left to resolve by averaging. And use two or three references, never one: one reference gets copied, three get interpolated, and interpolation is what you actually want. The craft lives in the distance between the examples you pick.

The Machinery: Two Skills

Two skills do the work, and both are quick installs.

figma-use is Figma's own foundational MCP skill: it lets Claude write to the canvas, instantiate real components, apply variables, and set auto-layout.

Your "apply design system" skill is one markdown file you author. It references design-tokens.md and components.md, states how to apply them ("always semantic tokens, never raw hex; pick the variant whose usage rule matches; ask before guessing"), and, critically, lists forbidden behaviors: no invented tokens, no new components, no gradients that do not exist in the token list, no arbitrary radii. The forbidden list is what suppresses the averaging drift. You are not teaching creativity; you are teaching discipline, and discipline is what a first pass needs. This file is the same species as the DESIGN.md pattern I described in the DESIGN.md AI design framework, specialized to one system.

Iterate Locally as HTML. Push to Figma Once.

The step most tutorials get backwards: they generate straight into Figma and iterate there, round-tripping every correction through the MCP server. Slow, token-expensive, and worse output.

The right sequence:

1. Prompt with everything loaded (tokens, components, references, content brief), asking for HTML with classes named after your tokens: bg-blog-raised, text-blog-ink-muted. Naming the tokens in the markup makes the output auditable; a raw hex in the generated HTML is a rule violation you can grep for.
2. Render the HTML in a browser. Critique specifically, not "make it better" but "the CTA uses the subtle action token on a conversion surface, use the bold one."
3. Loop two or three times while iteration is cheap text.
4. When the HTML is 90 percent there, push to Figma via figma-use, once. Real components, applied variables, named layers, auto-layout.

This local-first loop is how my blog redesign actually ran: baseline capture, local iterations against the token ramp, and a push only when the rubric passed. Figma (or in that case, production Blade templates) is the destination, not the workshop.

What Still Goes Wrong

Shipped honestly, the workflow's remaining failure modes:

• Typography misses most. Colors, spacing, and components land; then text-body-md shows up on a heading. Budget a few minutes of type cleanup per screen.
• Auto-layout direction occasionally flips in nested components. One-click fix, annoying tax.
• Literal values leak. The model sometimes writes the hex from your token table instead of the token class. The forbidden-behaviors preamble reduces this; auditing catches the rest.
• Dark-mode contrast parity needs a manual check. A combination that passes 4.5:1 in light can fail in dark even with both values defined.
• Soul is not included. The workflow produces correct screens, not memorable ones. The one unusual composition choice that makes your product feel like yours still comes from a human, and the skills that aim at taste, like the one I tested in my Impeccable design skill review, help precisely because they encode more opinion, not more rules.

The delta that matters: before structure, first passes needed structural rebuilds; after, cleanup is text styles and a contrast audit, editing instead of rebuilding. And the setup cost amortizes fast. The hours spent writing when-to-use sentences pay back on every generation afterward, and output from different team members converges because it is bounded by the same written system. For the broader visual pipeline this plugs into, see my Claude Design visual workflow.

Start With One Token Category Today

Open your design system. Pick one category, surface, text, or spacing, and write a one-sentence when-to-use description for every token in it. That is the whole unlock, applied once. Do every category this week and you will have a design system a model can actually follow, instead of a warehouse it can only average.

A month from now, the when-to-use sentences you write this week will still be earning, long after any prompt you tune in the meantime has been thrown away. The four brand systems this workflow maintains — the token-driven rebuild of this site's blog most recently — are collected in my project portfolio, which is the only fair evidence for whether the method beats the slop.