Prompting AI Builders with a Design System (On-Brand Generation)

The fastest way to get on-brand output from an AI page builder is to stop prompting it with adjectives and start prompting it with your design system: your actual color and spacing tokens, your real component names, and a short set of layout rules, all supplied as structured context rather than described in prose. Tools like v0, Bolt, Lovable, Cursor, and Claude-driven scaffolds will happily generate a plausible-looking page from a vague prompt, but "plausible-looking" and "on-brand" are different bars, and only the second one survives a design review. This guide covers how to structure that context, what to include and leave out, and how to review AI-generated UI against a system instead of against gut feel.

Why "Make It Look Good" Prompts Fail

Ask an AI builder for a "modern, clean pricing page" and you will get a modern, clean pricing page — for some brand. It will invent its own blue, its own border radius, its own spacing rhythm, and its own idea of what a card component looks like, because you gave it no constraints and a large language model trained on the entire visible web will default to the statistical average of "modern SaaS design." That average is a real aesthetic — it is also nobody's brand. The gap between what you asked for and what a design system enforces is the gap between a prompt describing a vibe and a prompt describing a system.

This matters more as AI-generated UI moves from throwaway prototypes toward code that actually ships. A one-off landing page mockup can absorb some off-brand drift; a component that lands in a production design system and gets reused across a dozen pages cannot. The cost of unconstrained generation is not the first page, it's the fortieth page that inherited the wrong button shadow because nobody caught it in review.

What "Feeding the AI Your Design System" Actually Means

A design system, for prompting purposes, is not your Figma file and it is not your marketing deck of brand values. It is a small, literal set of facts the model can copy from instead of infer. Four categories cover almost every case you'll run into.

1. Design tokens, not adjectives

Never tell an AI builder "use a professional blue." Tell it the token: --color-primary: #1B4F72 or, better, the semantic role name your codebase already uses — accent, surface, border, text-muted-foreground — pulled straight from your theme file. If your stack is Tailwind, paste the relevant slice of the @theme block or tailwind.config color scale directly into the prompt. If it's CSS custom properties, paste the :root variables. The model doesn't need your whole file, but it needs the literal values, not a description of them — "warm neutral gray" and oklch(0.87 0.01 90) are not the same instruction, and only one of them is reproducible across ten separate generations.

The same goes for spacing and radius scales. If your system uses a 4px base unit with a fixed set of steps (4, 8, 12, 16, 24, 32, 48), say exactly that and forbid arbitrary values. Most visible "AI slop" in generated UI — the slightly-off padding, the button that's almost but not quite the right height — traces back to the model picking a plausible-looking arbitrary number instead of snapping to your scale, because it was never told a scale existed.

2. Component inventory, named exactly

If you have a Button, a Card, and a Badge component already built — whether hand-rolled or from shadcn/ui — tell the model to use those exact import paths and prop names, and explicitly forbid it from inventing a new button variant or writing raw <button className="..."> markup. This single instruction eliminates most component-proliferation problems: left unconstrained, an AI builder will happily generate a new, slightly different button for every page it touches, because from its perspective each generation is a fresh task with no memory of the button it wrote three prompts ago.

Listing the component inventory as a flat, literal list works better than describing your design philosophy. "We use shadcn/ui primitives, extended with a PriceTag and StockBadge component in components/commerce/" is something the model can act on. "We value consistency and clean componentization" is not — it's the kind of line every design system claims and no model can operationalize.

3. Layout rules and forbidden patterns

A short list of explicit rules does more work than a long aesthetic brief. Useful examples: max content width and how it's expressed (a container class, not an arbitrary max-w-[1140px]), the grid or flex pattern your pages use for section layout, whether headings get their own spacing scale, and — critically — a list of things the model should never do: no inline style= attributes, no hex colors outside the token file, no new font-family declarations, no gradient backgrounds unless the brand actually uses them. AI builders default to certain "tells" (specific gradient combinations, a particular shadow style, emoji in headings) often enough that naming them as forbidden up front saves a review cycle.

4. Voice and copy constraints

Visual on-brand and verbal on-brand are both in scope, and both degrade the same way without constraints. If your brand doesn't use exclamation points, doesn't say "revolutionize," and writes in second person rather than third, say so directly, with one or two real examples of copy you'd actually publish versus copy you wouldn't. A short do/don't copy list prevents the generic "Supercharge Your Workflow Today!" headline that AI builders reach for by default when given a marketing-page prompt with no voice guidance.

A Reusable Prompt Structure

Rather than re-explaining your system in every prompt, build one reference block you paste (or, in tools that support it, attach as a file/system prompt) at the start of every session. A workable structure looks like this:

1. Role and constraint statement — "You are generating UI for [brand]. Use only the tokens, components, and rules below. Do not invent new colors, spacing values, or components."
2. Token block — the literal color scale, spacing scale, radius scale, and font stack, pasted as code, not prose.
3. Component inventory — a flat list of existing components with import paths and one-line descriptions of when to use each.
4. Layout rules — container width, grid conventions, spacing rhythm between sections, responsive breakpoints if they're nonstandard.
5. Forbidden list — the specific things the model tends to do wrong for your brand (inline styles, certain gradients, certain phrases).
6. Voice notes — two or three sentences of real copy that sound like the brand, and one line of copy that doesn't.
7. The actual task — what page or component to build, kept as its own short paragraph at the end so it doesn't get lost in the system context.

Keep this reference block under a page. A design system document that's ten pages long will get skimmed by a human reviewer and effectively truncated by context-window pressure on the model; a one-page block that's actually literal (tokens and component names, not philosophy) gets followed far more reliably. If you're starting a design system from a visual reference rather than an existing codebase, working from a structured UI kit — a Figma kit built with named components and a documented token set, like the ones in our Figma kit catalog — gives you a cleaner source to extract that reference block from than a screenshot or a live competitor site.

Reviewing AI Output Against the System, Not Against Taste

The review step is where most teams skip a beat. It's tempting to eyeball AI-generated UI and approve it if it "looks fine," but "looks fine" is exactly the judgment that let off-brand drift through in the first place — it's a taste check, not a systems check. A more reliable review asks a narrower, more mechanical question: does every value in this diff trace back to something in the token file or component inventory?

Grep before you eyeball

Before reviewing generated code visually, search it. Grep the diff for hex codes ('#[0-9a-fA-F]{3,6}'), for style= or styled, for arbitrary Tailwind values ('w-[', 'p-[', 'text-['), and for raw HTML tags where a component should have been used (<button, <input outside a form primitive). Any hit is a candidate for "the model invented something instead of reusing the system," and it's far faster to catch with a search than with a visual pass, especially on a large generation.

Diff the component tree, not just the render

Two pages can render almost identically while one uses your Card component and the other uses a hand-built div with matching padding. The second one looks fine today and diverges the moment your design system's card shadow changes, because it was never wired to the token. Reviewing the actual JSX/component tree — not just a screenshot of the output — catches this class of drift that a visual check alone will miss entirely.

Treat AI output like a first-time contributor's PR

The most productive mental model for reviewing AI-generated UI is the same one you'd apply to a capable but unfamiliar new contributor's first pull request: assume competence, assume no institutional memory. A new hire wouldn't know your button component is called Button and lives in components/ui/ unless someone told them, and neither does the model unless your prompt told it. That framing keeps the review focused on "did it follow the system" rather than "do I like what it made," which is both a fairer standard and a faster one to apply consistently across a team.

Common Failure Patterns and Their Fixes

A few failure modes show up often enough across AI page builders that it's worth naming them directly, along with the prompt-level fix for each.

• Color drift on repeated generations — the same prompt run twice produces two different shades of "brand blue." Fix: paste the literal token value or CSS variable name every time; never describe the color in words alone.
• Component reinvention — a new button, card, or badge appears that's almost identical to an existing one. Fix: name the exact existing component and forbid new variants explicitly, not just "reuse components where possible."
• Spacing that's close but not on-scale — 18px padding where your scale only defines 16 and 24. Fix: state the scale as a closed list and instruct the model to always round to the nearest defined step.
• Generic AI-builder tells — a specific purple-to-blue gradient, a particular card-hover lift, or emoji in section headers that show up across many different AI-generated sites regardless of brand. Fix: name these specifically as forbidden in your prompt; a general "make it on-brand" instruction won't override training-data defaults strongly enough on its own.
• Copy that reads like every other AI-generated landing page — "Unlock the power of," "Seamlessly," "Revolutionize." Fix: supply two or three real sentences of brand voice as positive examples; negative instructions alone ("don't sound like AI") are weaker than a concrete example to imitate.

Where This Fits in a Commerce Build

This discipline matters most in exactly the place teams are least likely to apply it: fast iteration on commerce pages, where a marketer or PM is using an AI builder to spin up a landing page or promotional layout without a designer in the loop for every change. The fix isn't to gate every AI generation behind a human designer — that defeats the speed advantage — it's to make the design system machine-readable enough that the AI builder can act as a competent extension of it. A well-documented token set and component inventory, the kind that comes out of a properly structured Figma kit or a componentized Shopify theme, is what makes that possible; a system that only exists as tribal knowledge or a static style guide PDF cannot be pasted into a prompt at all.

Frequently Asked Questions

Do I need a formal design system before I can prompt AI builders effectively?

You need the literal artifacts — token values, component names, a few layout rules — more than you need a formal, published design system document. A one-page reference block extracted from your actual codebase or Figma file is often more useful to an AI builder than a polished but abstract brand guideline, because the model can act on literal values in a way it can't act on descriptive language.

Does this approach work the same across v0, Bolt, Lovable, and Cursor?

The principle is identical — structured, literal context beats descriptive prompting — but the mechanism differs slightly. Some tools let you attach persistent project context or a system prompt once per project; others require you to paste the reference block into each new conversation. Check whether the tool supports a persistent context or rules file before assuming you need to repeat the full block every time.

How do I stop an AI builder from inventing new components every time?

Name the existing components explicitly by their real import path and prop signature, and add an explicit instruction forbidding new component creation unless nothing in the inventory fits. Vague instructions like "reuse components where possible" are followed inconsistently; a literal list with an explicit prohibition is followed far more reliably.

Is a visual review enough to catch off-brand AI output?

Not reliably. A visual check catches obvious mismatches but misses generated code that renders correctly today while quietly bypassing your token system or component inventory — code that will drift the moment the system's underlying values change. Pairing a visual pass with a quick grep for hex codes, inline styles, and arbitrary utility values catches most of what a visual review alone misses.