How to Avoid AI Slop When Using Claude Design (The Design System Approach)

Why Claude Design Outputs All Look the Same (And What to Do About It)

Open Claude Design, type a prompt, and you’ll get something that works. Clean layout, reasonable hierarchy, sensible whitespace. Now open it again with a different prompt. Same Inter font. Same muted blue accent. Same card-based structure. Same vibe.

That’s not a Claude problem. That’s a context problem.

Claude Design doesn’t know what your brand looks like. It doesn’t know your typeface choices, your color story, your spacing philosophy, or whether your UI should feel clinical or warm or loud. Without that context, it falls back on what it knows best: the aggregate visual style of every well-designed interface it’s trained on. Which, right now, looks a lot like a Tailwind starter template.

The fix isn’t a better prompt. It’s a design system — a reusable reference document you supply before you ask Claude to build anything. This article walks through exactly how to build one and how to use it so your Claude Design output looks like your product, not everyone else’s.

If you’re still getting familiar with what the tool actually does, this overview of Claude Design as a visual prototyping tool is a good starting point.

---

What “AI Slop” Actually Means in a Design Context

“AI slop” gets thrown around to mean low-quality AI output generally, but in UI design it has a specific signature:

• Inter or Geist as the default sans-serif
• Blue or indigo as the primary accent with subtle hover states
• Large rounded corners on every card and button
• Gradient hero sections with a headline, subheadline, and a CTA button
• Icon + label sidebar nav that looks like it came from Shadcn
• 50px+ padding everywhere because “clean and spacious” is the safe default

None of these are bad choices individually. They’re bad when they appear together in every single output regardless of whether you’re building a brutalist editorial site, a high-contrast B2B dashboard, or a consumer app targeting Gen Z.

The model isn’t making aesthetic judgments. It’s pattern-matching on “looks like a good UI.” Your job is to override that pattern with explicit constraints.

---

What a Design System Is (For This Purpose)

You don’t need a full Figma-based design system with component libraries and storybook documentation. For Claude Design, a design system is a structured text document — usually Markdown — that defines the visual rules Claude should follow for every output it generates.

Think of it as a style guide you paste into context at the start of a session, or reference repeatedly across a project.

At minimum, it should cover:

1. Typography — specific font names, weights, and size scales
2. Color palette — hex values with named roles (primary, surface, error, etc.)
3. Spacing system — the base unit and scale (e.g., 4px base, multiples of 4)
4. Component style — button shapes, border radii, shadow style, input treatment
5. Layout rules — grid system, max-widths, padding patterns
6. Visual personality — adjectives and anti-examples that describe the aesthetic direction

The more specific you are, the more distinctive the output. Vague rules produce vague results. “Use a dark theme” is too loose. “Background: #0A0A0A, surface cards: #141414, no border-radius above 6px, no drop shadows” is a constraint Claude can actually honor.

This is the same principle behind Google Stitch’s Design.md approach to AI design systems — and it works for the same reason: AI tools need explicit constraints to stay on-brand.

---

Step 1: Define Your Visual Vocabulary Before You Prompt

Don’t open Claude Design and start asking for screens. Spend 20 minutes first writing down your visual rules in plain text.

Typography

Don’t just say “use a serif font.” Name it.

Primary typeface: Instrument Serif (Google Fonts)
UI typeface: DM Sans
Monospace: Fira Code

Heading scale: 48px / 36px / 28px / 22px / 18px
Body: 16px, line-height 1.6
Small: 13px, line-height 1.5

Font weights: 400 (body), 500 (labels), 600 (headings)
No bold (700) anywhere except marketing hero text

If you don’t have specific fonts in mind yet, browse Google Fonts or pick from Anthropic’s own recommendations. The key is making a decision and writing it down.

Color Palette

Name every color with its role. This stops Claude from improvising.

--color-bg: #F5F0E8        /* warm off-white, main background */
--color-surface: #FFFDF8   /* card/panel surface */
--color-text: #1A1714      /* near-black, main copy */
--color-text-muted: #6B6560
--color-primary: #B84A2F   /* terracotta red, CTAs and links */
--color-primary-hover: #9A3A22
--color-border: #E0D9D0
--color-error: #C0392B

Include “do not use” notes if you know what you want to avoid. For example: “No blues or purples anywhere. No white backgrounds. No gray text on gray backgrounds.”

Spacing and Shape

Base unit: 4px
Common spacings: 4, 8, 12, 16, 24, 32, 48, 64

Border radius: 4px for buttons and inputs, 8px for cards, 0px for panels
No rounded-full / pill shapes
Borders: 1px solid, never 2px+

Shadows: single light shadow only, no multi-layer
  --shadow-sm: 0 1px 3px rgba(0,0,0,0.08)
  No elevation shadows or dramatic depth effects

Component Style Cues

Buttons: flat, no gradient, 4px radius, 14px uppercase tracking-wide label
Inputs: white fill, 1px border, focus ring in primary color
Tables: zebra striping in surface color, no outer border
Navigation: left sidebar, no icons, text-only links at 14px

Personality Tokens

These are harder to codify but worth including. Write 3–5 adjectives and 3–5 anti-examples.

Visual personality: editorial, warm, considered, slightly formal
Anti-examples: corporate SaaS, Stripe-lookalike, "startup modern", glassmorphism, dark mode default
References: Stripe Press, A24 website, Notion editorial pages

---

Step 2: Format Your Design System for Claude

You have two options for how to deliver this context to Claude Design: inline in your prompt, or as a reusable system prompt prefix.

Option A: Inline Prompt Prefix

Paste your design system at the top of your first message, then state what you want built.

## Design System

[paste your design system here]

---

## Task

Build a three-panel dashboard layout for a content calendar tool.
The left panel shows a list of scheduled posts. The center panel 
shows the selected post editor. The right panel shows publish 
settings and status.

Follow the design system above exactly. Do not introduce any 
colors, fonts, or border treatments not listed.

That last instruction matters. Without it, Claude may supplement your constraints with its defaults when it encounters a case you didn’t specify.

Option B: Project-Level System Context

If you’re building multiple screens or iterating across sessions, maintain your design system in a separate file and paste it fresh at the start of each conversation. Don’t assume Claude remembers previous sessions. It doesn’t.

Some teams keep a design-system.md file in their project repo and copy-paste from it as needed. This also keeps your design system in sync if you’re using Claude Design alongside Claude Code for UI and prototypes.

---

Step 3: Test Your System on a Single Component First

Before asking Claude to build a full page, test your design system on one isolated component. This is where you’ll catch gaps.

Ask for something specific:

Using the design system above, build a single primary CTA button 
in three states: default, hover, and disabled.

Inspect what comes back:

• Did it use your exact hex values?
• Is the border-radius correct?
• Did it invent a gradient or shadow you didn’t specify?
• Is the font correct?

If anything looks off, update your design system language to be more explicit, then retest. This is much cheaper (in time and tokens) than discovering inconsistencies after you’ve generated ten screens.

Speaking of tokens — if you’re using Claude Design for a longer project, having a tight design system actually helps you use tokens more efficiently because Claude spends less time making aesthetic decisions and more time executing.

---

Step 4: Lock In Layouts Before Adding Components

One of the most common ways AI design goes generic is at the layout level, not the component level. A terracotta CTA button on a standard hero-section layout still looks like every other AI-generated page — it just has a terracotta button.

Start with layout constraints.

Tell Claude:

This site does not use:
- Full-width hero sections with centered text
- Icon-grid "feature sections"
- Testimonial carousels
- Footer with three-column link lists

Instead, use editorial-style layout: long-form column, pull quotes, 
inline figures. Think magazine, not SaaS marketing page.

Explicit negative constraints are underused. Most people tell Claude what they want. Telling Claude what not to do removes the default patterns it would otherwise fill in.

This is the core of building branded interfaces that avoid generic AI aesthetics — it’s as much about blocking the defaults as it is about defining the positives.

---

Step 5: Iterate Within Your System, Not Around It

Once your design system is working, every follow-up prompt should reference it.

Bad iteration prompt:

“Make the header look more premium.”

“Premium” means Inter + subtle gradient to Claude. It’ll drift back to defaults.

Good iteration prompt:

“Make the header more visually distinct while staying within the design system. Consider using a larger type scale or a full-bleed colored bar using —color-primary.”

You’re giving Claude space to make a decision, but bounding it within your constraints. The result looks like a design choice you made, not a default Claude fell back on.

When you’re producing animated prototypes or slide decks, the same principle holds — your design system becomes the through-line that makes every screen look intentional. More on that approach in this guide to building animated prototypes with Claude Design.

---

Step 6: Maintain One Design System Document Across the Project

The most common failure mode is people rebuilding context from scratch in each session. They describe their style loosely, get inconsistent output, and blame the tool.

Your design system document is your source of truth. Keep it updated as you make decisions. If you decide mid-project to switch from 4px to 8px base radius, update the document and note the change.

Structure your final document like this:

# [Project Name] Design System

## Typography
...

## Color Palette
...

## Spacing & Shape
...

## Component Conventions
...

## Layout Rules
...

## Do Not Use
...

## Personality & Reference
...

## Changelog
- 2026-04-28: Changed base radius from 4px to 8px across all components
- 2026-04-22: Added --color-surface-2 for nested card backgrounds

The changelog prevents confusion when you’re iterating across sessions and can’t remember what you changed.

---

What to Borrow From Google Stitch’s Design.md Approach

Google Stitch handles this problem with a structured file called design.md — a machine-readable design system that gets passed to AI tools to ensure consistent output. The Design.md file concept is worth understanding even if you’re using Claude Design, because the underlying principle is identical.

The main difference is that Stitch generates and updates this file for you as you work. In Claude Design, you’re writing it manually. That’s more work upfront, but it also means you control every constraint exactly.

If you’re comparing tools and wondering which approach suits your workflow better, this head-to-head between Claude Design and Google Stitch is a useful read.

---

Common Mistakes That Produce Generic Output

Even with a design system in place, a few patterns consistently push output back toward generic.

Leaving font names generic. “Use a clean sans-serif” → Claude picks Inter. Always name the exact font.

Using color descriptions instead of hex values. “Use a warm red” → Claude interprets this differently every time. Use exact hex values.

Not specifying what you DON’T want. If your design system is silent on shadows, Claude adds shadows. If it’s silent on border radius, Claude adds rounded corners. Silence equals defaults.

Regenerating without fixing the system first. If an output is off-brand, the instinct is to regenerate. The right move is to find the gap in your design system that allowed the deviation, fix the document, then regenerate.

Not testing on components before pages. Component-level issues compound quickly when you move to full layouts.

---

How Remy Approaches This Problem at a Higher Level

The design system approach described above is effective. But it’s still a manual process — you’re writing constraints, pasting them into context, managing a document, and hoping Claude follows the rules consistently.

Remy takes a different approach. Rather than feeding constraints into a prompt each time, the design specification lives in the app’s spec document — the same source of truth that defines the backend, data model, and business logic. When you describe your interface in the spec, you define visual constraints alongside functional ones. They’re part of the same artifact.

This matters because the spec is the source of truth — not the code, not the prompt history. When you iterate, you update the spec. The design constraints stay in sync with everything else. You’re not re-pasting a design system into a new conversation hoping Claude picks it up correctly.

If you’ve run into the typical failure modes of AI-generated apps in production — inconsistency across screens, drift over iterations, visual decisions that don’t survive a regeneration — the spec-driven model addresses the root cause rather than the symptom.

You can try Remy at mindstudio.ai/remy.

---

FAQ

Why does Claude Design always produce the same visual style?

Claude Design doesn’t have brand context unless you provide it. Without explicit constraints on fonts, colors, spacing, and layout patterns, it defaults to the aggregate visual style it’s trained on — which tends to look like a well-executed Tailwind or Shadcn template. Providing a design system document at the start of each session gives Claude the constraints it needs to produce distinctive output.

How specific does a design system need to be for Claude Design to follow it?

Specific enough that there’s no ambiguity in any common case. That means exact hex values (not color descriptions), exact font names (not categories like “serif” or “modern”), pixel values for spacing and radius, and explicit negative rules for patterns you want to avoid. Vague language produces vague output.

Can I reuse my design system across multiple Claude Design sessions?

Yes, and you should. Keep your design system in a plain Markdown file and paste it at the start of every new session. Claude Design doesn’t retain memory between sessions, so starting fresh without context will produce inconsistent results. Some teams store this file in their project repository alongside other design documentation.

What’s the difference between a design system for Claude Design and one for a tool like Figma?

A Figma design system is a visual component library — reusable design tokens, component variants, and layout structures you work with visually. A Claude Design design system is a text document of constraints you feed into a language model to constrain its output. The underlying goal (consistency and brand fidelity) is the same, but the mechanism is entirely different. You’re writing rules for an AI, not building visual components.

Does this approach work for animated prototypes, not just static screens?

Yes. Your design system controls the visual identity, and animations are a separate layer on top. The typography, colors, spacing, and component treatment you define will carry through into animated output just as they do in static screens. For more on building animated prototypes, see Claude Design’s approach to animated prototypes and slide decks.

How do I know if my design system is working?

Test it on a single isolated component first — like one button in three states. If the output matches your spec exactly, the system is working. If Claude improvises details you didn’t specify, find the gap in your document and fill it. Iterate on the design system before iterating on the interface.

---

Key Takeaways

• Claude Design defaults to generic output because it lacks brand context. The fix is a design system document, not a better prompt.
• A working design system includes: exact font names, hex values with named roles, pixel-level spacing and radius rules, component conventions, and explicit negative constraints.
• Test your system on a single component before building full layouts.
• Maintain one design system document across the project and update it as decisions change.
• Silence in your design system = Claude defaults. Every unconstrained decision will revert to the norm.
• For teams building full applications rather than static prototypes, try Remy — the design specification lives in the same spec document as everything else, so constraints stay consistent across iterations.