How to Build a Design System in Claude Design That Doesn't Look Like AI

Why Claude Design Keeps Producing the Same Interface

Open Claude Design and ask it to build something. Chances are you’ll get a card-based layout with rounded corners, a sans-serif typeface at exactly the weight Claude favors, a soft gradient hero, and a color palette hovering somewhere between “tech startup teal” and “corporate blue.” It works. It’s competent. And it looks like every other AI-generated interface you’ve seen this month.

This isn’t a bug. Claude Design’s defaults are calibrated to produce safe, functional output. The model is optimizing for “looks like a real app,” and the training data for “real app” is heavily skewed toward a narrow aesthetic band. The result is a kind of convergence — every AI tool reaches for the same design vocabulary when left to its own devices.

The good news: Claude Design gives you enough control to break out of this. You just have to stop treating it like a magic box and start treating it like a collaborator who needs specific direction. This guide covers exactly how to do that — using reference screenshots, Skill UI, and what practitioners are calling the Taste skill to build a design system that looks like you made a decision, not a default.

If you’re new to the tool, this overview of Claude Design as a visual prototyping tool is worth reading first.

Understanding What “AI Aesthetics” Actually Means

Before you can fix something, you need to name it precisely.

The generic AI aesthetic isn’t one thing — it’s a cluster of habits the model falls into when it has no other signal:

Neutral sans-serif typography — usually Inter, DM Sans, or something indistinguishable from them, set at predictable weights
Card-heavy layouts — everything in a rounded-corner container with a light drop shadow
Low-contrast gradients — particularly in hero sections, going from one blue to a slightly different blue
Icon overuse — every list item gets a small outlined icon, regardless of whether it helps
Safe spacing — generous padding, everything aligned to an 8px grid, nothing surprising
Muted color palettes — slate grays, off-whites, and one “accent” color that is almost always blue or purple

None of these choices are wrong, exactly. But they’re not choices — they’re defaults. A design system built on defaults communicates nothing about your brand, your users, or what you value.

The death of the mockup is happening, but it only works in your favor if the output is actually yours.

Step 1: Stop Starting From a Blank Prompt

The single biggest mistake people make with Claude Design is opening a fresh session and describing what they want in words alone. Words are ambiguous. “Modern” means something different to every person who types it. “Clean” to Claude means minimal — but minimal to a Japanese design studio looks completely different than minimal to a SaaS startup.

Visual reference is the highest-bandwidth input you have. Use it.

How to Use Reference Screenshots Effectively

Claude Design accepts image uploads. Your workflow should start there, not with text.

What to upload:

Screenshots of interfaces you genuinely admire — not AI-generated interfaces, but real products with a distinctive visual identity
Brand photography or mood board images that capture the feeling you’re after
Typography specimens if you have a specific typeface in mind
Color palette images, even just swatches

How to frame the reference: Don’t just upload and say “make it look like this.” Be explicit about what you’re extracting. For example:

“Here’s a reference screenshot. I want to match the typographic hierarchy — notice how the display text uses tight leading and a condensed weight, while body copy stays regular. I’m not copying the layout, just the type treatment.”

Or:

“This image captures the color temperature I want — warm off-white background, deep ochre accents, dark brown text instead of black. Use these as the basis for my palette.”

Breaking the reference into components (type, color, spacing, layout) gives Claude specific dimensions to work with instead of an impossible “replicate this” instruction.

Building a Reference Library

Before you start any serious project in Claude Design, spend 20 minutes collecting 8–10 screenshots that represent different aspects of what you want. Store them somewhere accessible. You’ll upload different ones at different stages of the build.

This reference library becomes your design system’s source of truth before you’ve written a single component.

Step 2: Define Your Design Tokens First

A design system is just a set of decisions. Tokens are the formal version of those decisions — your colors, type scale, spacing scale, border radii, and shadow styles locked down before anything else.

Claude Design will generate tokens implicitly if you don’t specify them. That implicit set is where the generic aesthetics live.

Here’s how to make them explicit.

Building a Token Prompt

Before you build any screens, start with a dedicated prompt that establishes the visual language. Structure it like this:

Design token specification for [project name]:

TYPOGRAPHY
- Display: [specific typeface], [weight], [tracking]
- Heading: [typeface], [weight], [tracking]  
- Body: [typeface], [weight], [line height]
- Caption: [typeface], [weight], [size]

COLORS
- Background: [hex or description]
- Surface: [hex or description]
- Primary: [hex]
- Secondary: [hex]
- Text primary: [hex]
- Text secondary: [hex]
- Border: [hex or description]

SPACING
- Base unit: [px value]
- Scale: [e.g., 4, 8, 12, 16, 24, 32, 48, 64]

BORDER RADIUS
- Small: [px]
- Medium: [px]
- Large: [px]
- Full: [e.g., 9999px for pills]

SHADOWS
- [Description of shadow style — or "none" if flat]

Send this before any UI work. Ask Claude to confirm it understood the token system. Then reference it by name in subsequent prompts (“use the token system we defined”).

This creates a consistent reference frame that Claude can apply instead of reaching for defaults.

Step 3: Use the Taste Skill

In Claude Code, skills are reusable instruction sets that encode a specific process or preference. The Taste skill is an emerging pattern where you capture your aesthetic judgment in a structured format that Claude can apply consistently.

Think of it as a standing brief for your visual sensibility — written down, not re-explained every session.

What Goes Into a Taste Skill

A Taste skill for design purposes typically includes:

Things you always want:

Typography choices and the reasoning behind them
Color constraints (e.g., “never use pure black — use a very dark warm gray instead”)
Layout preferences (e.g., “prefer asymmetric compositions over centered hero layouts”)
Animation style (e.g., “subtle easing, never bouncy spring physics”)

Things you never want:

Specific elements to avoid (e.g., “no stock-photo-style hero images,” “no gradient overlays on text”)
Layout patterns that feel generic (e.g., “no three-column feature grids with icons at the top”)
Typography habits to suppress (e.g., “don’t use Inter or DM Sans”)

Reference examples:

Named products or brands with design sensibilities you want to channel
Specific designers or studios whose aesthetic informs yours

How to Structure It

The Claude Code skills architecture is worth understanding here. Skills work best when they’re process-focused and specific, not vague. Your Taste skill should read more like a precise brief than a list of adjectives.

Bad: “Make it look sophisticated and modern.”

Good: “Use uppercase labels with wide letter-spacing for navigation and metadata. Prefer left-aligned text over centered text except in very specific hero moments. Type sizes should feel slightly large — err on the side of generous.”

Store this as a markdown file you can paste into new sessions. Over time it becomes a genuine asset — taste as something you’ve built and can apply, not a vibe you try to describe from scratch every time.

Step 4: Work With Skill UI for Component Consistency

Claude Design can generate individual screens, but the challenge is keeping components consistent across screens. The button style in screen one shouldn’t diverge from screen three.

Skill UI is a pattern for solving this. It means defining a UI component library — either as a standalone skill or as part of your project’s design system file — that Claude references every time it generates a new screen.

Building Your Component Library

Start with the components you use most:

Button variants — primary, secondary, ghost, destructive; small, medium, large
Input fields — default, focus, error, disabled states
Cards — content card, action card, stat card
Navigation — top nav, sidebar, mobile nav
Typography components — headings, body, captions, labels, badges

For each component, define:

What it looks like (or provide a screenshot reference)
What states it has
What it’s never used for

The Reference File Approach

Create a design system reference file (a markdown doc works fine) that describes all your components in one place. When you start a new screen, include the instruction: “Build this screen using the component system defined in [reference file].”

This is analogous to how Google Stitch uses a design.md file to maintain consistency across an AI-generated project. The principle is the same regardless of tool: give the AI a persistent reference it can look up instead of inventing from scratch.

Step 5: Direct Claude Away From Its Defaults Explicitly

Sometimes the most effective approach is direct negation. Claude’s defaults exist in its training. You override them by being explicit about what you don’t want.

Effective Negative Prompting

These instructions are worth keeping in your standard project setup:

“Do not use Inter, DM Sans, or Nunito for this project.”
“Avoid rounded-corner card containers as the primary layout pattern.”
“No gradient hero backgrounds.”
“Don’t add decorative icons to list items unless I specify them.”
“Borders should be used sparingly — prefer whitespace to separate sections, not lines.”
“Avoid the color blue unless it’s part of the token system I’ve defined.”

Pair each negative instruction with a positive alternative. “Don’t do X” is clearer when you add “instead, do Y.”

The ‘Not the Default’ Instruction

A blunt instruction that actually works: “This interface should not look like it was generated by an AI. Avoid every design pattern that appears frequently in AI-generated UI. Make a strong, opinionated choice on typography, color, and layout — then commit to it.”

It sounds simple, but Claude’s response to this instruction tends to be noticeably different from its default output. It’s essentially asking the model to move away from its modal output, which it can do with some prompting.

Step 6: Iterate With Visual Critique Prompts

Most people edit Claude Design output through positive revision: “make the header bigger,” “change the button color.” This is slow.

Visual critique prompts are faster. Instead of specifying a fix, describe what’s wrong:

“This looks too generic — specifically the typography feels like a placeholder, not a deliberate choice. The font size hierarchy is too subtle. Fix just the typography.”
“The layout is too symmetrical. Break the grid in at least one section — not randomly, but with intent.”
“The color palette is fine but it’s not doing anything. Find one place where the accent color can be used in an unexpected way — not just on the primary button.”

This kind of critique prompt forces Claude to diagnose and fix a specific design problem rather than just executing a mechanical change.

If you’re comparing this workflow to other AI design tools, the Claude Design vs Figma comparison covers when iteration in Claude actually outpaces traditional design tools, and when it doesn’t.

Step 7: Export and Maintain Your Design System

Once you’ve built a design system that works — tokens defined, components consistent, aesthetics deliberate — you need to maintain it. AI tools have no memory across sessions by default. What you built today is invisible tomorrow unless you capture it.

What to Export and Store

Your token specification document
Your Taste skill file
Your component library reference
3–5 screenshots of output you’re happy with (for future reference prompts)

Keep these in a folder alongside your project. Before any new Claude Design session for this project, paste the relevant files in at the start. Treat them as your project’s design system documentation.

When to Update the System

Your design system should evolve as the project does, but not arbitrarily. Update it when:

You discover a component pattern you keep needing that isn’t in the library
A token (usually a color or type size) isn’t working in practice
You see Claude drifting toward a pattern you didn’t intend — add a new negative instruction

Resist the urge to update it after every screen. Stability is the point.

Where Remy Fits in This Workflow

Claude Design handles the visual layer — what the interface looks like. But if you’re building something real, there’s a backend behind those screens, and that’s where things get complicated.

The pattern that works well: use Claude Design to build and refine your visual design system, generate your component library, and prove out your interface decisions. Then bring that into a full-stack build.

Remy handles the full-stack side — backend, database, auth, deployment — from a spec document that describes what the app does. Your Claude Design output (screenshots, component descriptions, design tokens) can feed directly into that spec as the visual reference. The spec carries both the functional requirements and the aesthetic decisions.

This matters because spec-driven development gives you a persistent source of truth — not a chat log of prompts, but a structured document that stays in sync as the project evolves. Your design decisions don’t live only in Claude Design’s memory. They live in the spec, alongside the data model and the business logic.

You can try Remy at mindstudio.ai/remy.

Common Mistakes to Avoid

Relying on Style Adjectives Alone

“Minimalist,” “modern,” “clean,” “premium” — these words are almost useless as design instructions. They’re too ambiguous and Claude’s interpretation of them is whatever its training data says they mean. Use visual references and specific constraints instead.

Iterating on Layout Before Locking Tokens

If you’re changing colors and fonts in the same session where you’re refining layout, your system will drift. Lock the token system first. Don’t touch it until the layout is settled. Then revisit tokens with fresh eyes.

Building Screens Before Building Components

It’s tempting to start with the homepage hero and work outward. But components built as a system are more consistent than components built screen-by-screen. Define your button, your card, your input — then build screens from those pieces.

Not Testing Edge Cases

AI-generated interfaces often look good in the happy path and break down in edge cases: long text in a card, empty states, error messages, mobile views. Build these early. The design system needs to handle them, and you’ll find gaps faster than you think.

Frequently Asked Questions

Does Claude Design have a built-in way to save a design system?

Not across sessions in a persistent way. Claude Design doesn’t maintain memory between separate conversations. You have to export your design system documentation — tokens, component specs, Taste skill file — and paste it into new sessions manually. Some teams keep this in a shared Notion document or a simple text file in their project folder.

Can I use a custom typeface in Claude Design?

You can specify any typeface you want and Claude will incorporate it into the generated code. The font will need to be available via a CDN (Google Fonts, Adobe Fonts) for it to actually render in the output. If you’re using a proprietary typeface, you’ll need to handle the font loading separately after export.

What’s the difference between a Taste skill and a style prompt?

A style prompt is a one-time instruction you write in a single session. A Taste skill is a document you maintain and reuse. The Taste skill builds up over time — you add things that worked, remove things that didn’t, and refine the language. A style prompt is ad hoc. A Taste skill is an asset. The difference between taste and conviction in AI work is worth understanding if you want to get better at this.

How does Skill UI differ from just describing a component in a prompt?

Describing a component in a prompt generates that component once. Skill UI is a reference system — you define the component, give it a name, and then every subsequent prompt can say “use the card component from the Skill UI library” instead of re-describing it. The distinction matters when you’re building more than a few screens. Without a Skill UI reference, components drift.

Should I use Claude Design or Claude Code for UI work?

Depends on where you are in the process. Claude Design is better for visual exploration, design system definition, and prototyping. Claude Code is better when you’re building toward production and need the code to be precise, maintainable, and integrated with a real backend. The comparison between Claude Design and Claude Code for UI covers this in more detail. The short answer: use Claude Design first, then Claude Code when you’re ready to build.

Can I use reference screenshots from competitor products?

Technically yes, but be thoughtful. Using a competitor’s UI as direct reference risks your product looking like a derivative. Use competitor screenshots to identify what you want to avoid, not what you want to copy. For positive reference, look at products in adjacent categories that have strong design identity — the aesthetic principles transfer without the risk of convergence.

Key Takeaways

Claude Design defaults to a recognizable set of safe design choices. None are wrong, but none are distinctive.
Reference screenshots are your highest-leverage input. Use them before writing any text prompts.
Lock your design tokens first — colors, typography, spacing, radius — before building any screens.
A Taste skill is a reusable document that encodes your aesthetic preferences. Maintain it like code.
Explicit negative instructions (“avoid card-heavy layouts,” “don’t use Inter”) are as useful as positive direction.
Export and store your design system after every session. Claude has no cross-session memory.
For full-stack builds, Remy lets you carry your design decisions into a spec that drives the entire application — not just the UI layer.