How to talk about design with Claude
Prompt patterns for design tasks: how to provide references, describe constraints, iterate effectively, and get predictable results. The difference between subjective requests and structural prompts.
Structural request vs. subjective taste
A taste-based request asks for subjective judgment without criteria:
"Make me a beautiful dashboard"
A structural request has concrete, verifiable criteria:
"Create a dashboard layout: sidebar 240px, main content max-width 1200px, header 56px with breadcrumbs. Color scheme: background #FAFAFA, accent #3B82F6, text #1A202C. Typography: Inter."
Claude works well with the second type and poorly with the first.
Seven patterns for design prompts
1. Reference + difference
Create a navigation sidebar in the style of Linear.app.
Difference: no icons in collapsed state, text only.
Tech stack: React + Tailwind CSS.
2. Problem + constraints
I have a registration form: 8 fields on one page, high dropout rate.
Constraints: can't remove required fields, no progressive disclosure (product requirement).
Suggest three layout variations that reduce cognitive load.
3. Iteration with preservation
Here's the current design.md: <paste>
Keep everything as is, but:
- Replace the accent color from blue to emerald
- Increase border-radius to 10px everywhere
- Add a Toast component with 4 variants (success, error, warning, info)
4. Critique with prioritization
Here's my current interface: <description or screenshot>
Find issues. Prioritize by: impact on conversion vs. implementation cost.
Give me the top 3 fixes that deliver maximum value for minimum effort.
5. Component with states
Create a Button component:
- Variants: primary, secondary, ghost, danger, loading
- Sizes: sm (h-8), md (h-10), lg (h-12)
- States for each variant: default, hover, active, disabled
Format: Tailwind CSS + TypeScript props
6. Accessibility check
Here's my color palette: primary #2563EB on white, secondary #9CA3AF.
Check contrast against WCAG AA (4.5:1 for text, 3:1 for large text and UI).
Where it fails — suggest alternatives with the same hue.
7. Design-to-code
Here's design.md: <paste>
Implement a Card component in React + CSS Modules.
Strictly follow the design system: no values outside the tokens.
Add variants: default, featured (accent left border), minimal (no shadow).
How to iterate correctly
Wrong iteration:
"No, that's not it, redo it" — Claude doesn't know what's wrong
Right iteration:
"Good, but:
Pick a component you want to improve in your project (or take any button/card). Ask Claude three times: first — an open request ('make it good'), second — a structural request from pattern #5, third — iteration with specific changes. Compare the quality of all three outputs.
Copy and adapt to your context. Text in angle brackets should be replaced.
Create a <component name> for <product type>. Design system: - Colors: background <hex>, accent <hex>, text <hex>, border <hex> - Typography: <font>, <sizes> - Spacing: base unit <px>, rounded corners <px> Component variants: <list> States: <list> Tech stack: <React/Vue/HTML/Tailwind/CSS Modules> Strictly use only values from the design system above. No hardcoded values outside tokens.
- Iterating with "that's not it, redo it" — without specifics Claude guesses, and usually guesses wrong.
- Not specifying the tech stack — Claude chooses something you're not using.
- Asking for too much in one prompt — "design the whole app" yields shallow results. One component at a time.
- Start with "Stop. Ask me 3 clarifying questions before you begin" — surfaces gaps in your prompt before Claude starts working.
- "Think out loud before designing" — Claude describes its reasoning, you approve or redirect before it writes any code.
- Save good prompts as team templates — a solid "component prompt" works 100 times over.
Any new component, iteration on existing design, accessibility audit, generating states.
When you need emotional user reactions to the design — that's user testing, not AI.