Get Started with Claude Design
Claude Design is Anthropic's text-to-prototype tool. Describe a screen, get a working interactive prototype back. This guide shows you how to prompt it effectively.
The situation
You have tried Claude Design. Every prototype came back looking like a generic SaaS dashboard with a blue header and a grid of cards. You know the tool can do better but your prompts are not working.
You'll learn the prompt pattern that produces specific, context-aware output and how to iterate on one thing at a time without losing what was already working.
What you walk away with
The prompt structure that produces specific, context-aware prototypes instead of generic templates
How to iterate on one change at a time without triggering a full rewrite
A live prototype URL and a written component spec ready to hand to a developer
Write a brief that specifies context, not just appearance
The most common mistake with Claude Design is describing how the screen should look instead of what it needs to do. A prompt that says "clean, modern, minimal" produces every other SaaS dashboard. A prompt that specifies audience, flow, and constraints produces something useful.
Design a mobile onboarding screen for a savings app.
Target: first-time smartphone users in Bangladesh.
Show a progress bar at the top (step 1 of 3), a friendly illustration
placeholder, a headline ("Save a little every day"), a subtext line,
and a large primary CTA button.Iterate on one thing at a time
Claude Design generates working code, which means you can iterate on it. Ask for one change at a time: adjust the layout, swap the color, add a state. Asking for five changes at once produces a rewrite that drifts from what was working.
The illustration is too large on small screens. Replace it with an icon
(piggy bank or similar). Keep the progress bar and reduce overall padding
so the CTA button is always above the fold on a 5-inch screen.Export the prototype and hand it off
Once the prototype does what you need, export the generated code or copy it directly. You can paste it into a Claude Code session for further development, share the live URL for stakeholder review, or use the code as a written component specification (reference spec) for the development team.
Generate a written spec for the developer. Include: component list,
exact copy for each text element, color tokens used (use my working
agreement for the token names), and the mobile breakpoint assumptions.Common mistakes
Four failure modes when using Claude Design.
- Describing appearance instead of purpose. "Clean and modern with a blue header" gives Claude aesthetic direction but no functional constraints. Describe who uses it, what they are trying to do, and what constraints they are under. The aesthetic follows from that.
- Iterating in batches. Asking for five changes at once produces a rewrite. Each change you request touches different parts of the prototype. One at a time keeps each iteration reviewable and reversible.
- Treating the prototype as final. Claude Design prototypes are fast to generate and fast to throw away. They are for testing an idea, not shipping a product. Before the code goes to a developer, it needs a cleanup pass: proper types, real API calls, accessibility attributes.
- Not exporting the spec. A live prototype URL works for demos but not as a handoff document. The written component specification (reference spec) is what a developer can build from without needing to open the prototype. Generate it before closing the session.
What's next?
Synthesize user research with ClaudeNew guides, when they ship
One email, roughly weekly. CLAUDE.md templates, workflows I actually use, and the cut-for-length stuff that does not make the public guides. One-click unsubscribe.
Or follow on Substack