4.1 Why Design Prompts Are Different

Why Design Prompts Are Different

Prompts for visual design outcomes require a different approach than prompts for code functionality. The gap between "I want it to feel premium" and actual CSS properties is wider than most people expect.

A coding prompt asks for a function that does something. The output either works or it does not. A design prompt asks for visual qualities: spacing, color, hierarchy, mood. The output exists on a spectrum from generic to precise. The difference matters because Claude has a default aesthetic it falls back to when instructions are vague.

Generic AI design output often drifts toward a polished but familiar house style: soft backgrounds, large type, warm accents, rounded cards. This is not bad. It is what happens when you have not specified a stronger system. The more concrete your instructions, the more you override generic defaults.

The second prompt produces output. It might even look decent. But it will not match your design intent, because "modern" and "premium" and "nice" mean something different to Claude than they do to you. The first prompt leaves no ambiguity. Every visual decision is specified or delegated intentionally.

4.2 The Design-to-Code Translation Layer

The Design-to-Code Translation Layer

Designers and CSS speak different dialects of the same language. Learning the mapping between design concepts and CSS properties is the single most effective way to improve your prompts.

You do not need to learn CSS syntax. You need to learn the vocabulary — the property names that Claude uses to construct layouts. Think of it like learning enough of a language to give directions. You are not writing a novel. You are saying "turn left at the corner."

This table is your Rosetta Stone. When you want to communicate a design concept to Claude, find the concept in the left column and use the phrase from the right column in your prompt. You do not need to memorize CSS syntax. Claude handles that. You need the vocabulary.

Claude mirrors whatever CSS approach your project already uses. If your project has Tailwind, Claude writes Tailwind classes. If it has CSS Modules, Claude writes CSS Modules. If it has vanilla CSS with custom properties, Claude writes vanilla CSS. This means you can specify the approach in your prompt if it matters: "Use Tailwind classes matching the existing components" or "Write vanilla CSS in a style tag."

4.3 Prompt Patterns for Common Design Tasks

Prompt Patterns for Common Design Tasks

These templates are tested and ready to copy. Each one covers a specific design task with the key details Claude needs to produce reliable output.

The templates follow a consistent structure: specify the component, define the visual specs, reference existing patterns, and set verification expectations. Fill in the bracketed values with your project's specifics.

Three of these templates deserve fuller treatment. Here is how each one looks when filled in for a real task.

Layout: Dashboard with sidebar

Create a dashboard layout with:
- Sidebar: 240px fixed width on desktop, collapsible to hamburger on mobile
- Main content area fills remaining space, 32px padding
- Header bar: 64px height, sticky, white background, subtle bottom border
- Content grid: auto-fill, minmax(320px, 1fr), 24px gap
- Use CSS Grid for overall layout, Flexbox for component internals
- Reference the existing layout in @src/components/AppLayout.tsx

Component: Card with screenshot reference

Build a card component matching the design in this screenshot:

[Paste screenshot]

Requirements:
- Border radius: 12px
- Shadow: 0 1px 3px rgba(0,0,0,0.1)
- Padding: 24px
- Image: 16/9 aspect ratio, object-fit cover
- Title: 20px, semibold, single line with ellipsis truncation
- Description: 14px, regular, 2-line clamp
- Hover: translateY(-2px) with shadow intensifying
- Transition: 200ms ease

Follow the card pattern in @src/components/ProductCard.tsx.

Design exploration: Propose before building

I'm building a fintech dashboard for small business owners.

Before building, propose 4 distinct visual directions.
Each as: background hex / accent hex / typeface / one-line rationale.

Wait for me to choose, then implement only that direction.

The "propose options" pattern is worth highlighting. When you are unsure about direction, asking Claude to propose options before building produces meaningfully different visual directions across runs. It also prevents Claude from defaulting to its editorial aesthetic, because you are choosing from a menu instead of accepting whatever it produces first.

4.4 When to Show vs Tell

When to Show vs Tell

Claude Code can read images. This changes everything about how you prompt for visual design work, because sometimes a screenshot communicates more precisely than any text description.

There are three ways to give Claude an image: drag and drop a file into the Claude Code window, paste from your clipboard (Ctrl+V in terminal, standard paste in Desktop app and VS Code), or reference a file path in your prompt.

The rule is straightforward. Use images when you want Claude to match a visual. Use text when you want Claude to follow exact specifications. Use both when you want the best results.

The hybrid approach wins because the screenshot gives Claude the visual goal and the text gives Claude the exact specifications. Claude can see the overall composition from the image and use the text values for colors, fonts, and spacing. Then the "take a screenshot and compare" instruction creates a verification loop.

Text descriptions work better than images for exact color values (hex codes are unambiguous), typography specs (font names and weights are precise), layout measurements (pixel values leave nothing to interpretation), interaction behavior (hover states are easier to describe than to show), and accessibility requirements (ARIA labels and contrast ratios are text by nature).

Images work better than text for overall composition and layout, visual style references from other sites or designs, matching an existing design, and communicating a mood or aesthetic that is hard to put into words.

4.5 Iteration Patterns

Iteration Patterns

Basic refinement — "make the heading bigger" — is what you learned in Chapter 3. This section teaches three named iteration patterns that produce better results than ad-hoc corrections.

These patterns are not about writing better initial prompts. They are about what you do after the first generation, when the output is close but not right. The pattern you choose depends on what kind of gap exists between the output and your intent.

Pattern 1: Explore-Plan-Build

Use this when you are building something new and want Claude to understand your project before writing code. The pattern has three phases.

Phase one — explore. Ask Claude to read your existing files and understand the design system before proposing anything:

Read @src/components/ and @src/styles/ and understand the design system:
- What CSS approach is used?
- What are the existing color and spacing tokens?
- What component patterns exist?

Summarize what you find before proceeding.

Phase two — plan. Ask Claude to create an implementation plan based on what it found:

Based on the existing design system, create a plan for a pricing page:
1. Which components should be reused vs created new?
2. What is the layout structure?
3. List every component with its specs.

Do not write code yet. Wait for my approval.

Phase three — build. Only after the plan is approved:

Implement the pricing page from your plan.
Follow the design system in @src/styles/tokens.css.
Take a screenshot when done and compare to the design spec.

This pattern takes longer upfront but produces output that fits your project from the start, because Claude has context about your existing patterns before it writes a single line.

Pattern 2: Screenshot-Driven Iteration

Use this when you have a visual target — a mockup, a reference design, or a previous version you want to match. The pattern loops until the output matches the target.

[Paste design mockup]

Implement this design.
After implementing, take a screenshot and compare to the original.
List every visual difference.
Fix each difference.
Repeat until the output matches the mockup.

This is the highest-leverage iteration pattern for visual work. Claude becomes its own quality checker. It builds, it looks, it compares, it fixes. The loop converges on the target design without you having to describe every discrepancy in words.

Pattern 3: Clear-and-Refine

Use this when the first output is going in the wrong direction and incremental corrections are not helping. Instead of correcting the same session, reset and start fresh with a better prompt.

The pattern works like this: you note what is wrong with the first attempt, run /clear to reset the conversation context, then write a new prompt that incorporates the lesson from the failed attempt. The fresh context combined with a better-informed prompt produces better results than accumulated corrections in a cluttered session.

Once Claude has built something you are happy with, lock the design decisions into CLAUDE.md so they persist across sessions:

## Design System

- Card component: 12px radius, 24px padding, shadow 0 1px 3px rgba(0,0,0,0.1)
- Color palette: --primary: #2563EB, --bg: #FFFFFF, --text: #1A1A2E
- Typography: Inter, scale 14/16/20/24/32/48px
- Spacing: 8px base unit (8, 16, 24, 32, 48, 64, 80)
- Border radius: 12px cards, 8px buttons, 9999px pills
- All future components follow this system.

This uses Claude Code's memory system. Every new session reads CLAUDE.md before responding, so your design decisions carry forward without you restating them.

4.6 Prompt Antipatterns

Prompt Antipatterns

These are the mistakes I see most often. Each one produces bad output in a predictable way. Recognizing them is faster than learning every good pattern.

These antipatterns have one thing in common: they leave too much room for interpretation. Every antipattern can be fixed by replacing subjective language with concrete specifications. The fix is always the same: be specific about what you want instead of vague about what you do not want.

The negative prompt gives Claude a list of things to avoid but no direction on what to pursue instead. Claude will pick a different default — often equally generic. The positive prompt gives Claude a complete specification to target. Both prompts take roughly the same effort to write. One produces predictable results.

Here is a mental checklist for every design prompt before you send it:

• Did I specify colors with hex values or variable names?
• Did I name the fonts and weights?
• Did I describe the layout with specific values (columns, gaps, max-width)?
• Did I reference existing files that Claude should follow?
• Did I include a verification instruction ("take a screenshot and compare")?
• Did I avoid subjective terms without concrete definitions?

If you can answer yes to all six, send it. If not, fill in the gaps. The thirty seconds you spend sharpening the prompt saves minutes of iteration.

Good prompting is not a talent. It is a skill that develops with practice, and it has concrete, learnable patterns. The translation layer between design thinking and code output is the core skill this book teaches. The tables and templates in this chapter are your reference. Come back to them whenever the output is not matching your intent. The gap between what you imagined and what Claude produced is almost always a translation problem — and translation problems have concrete fixes.