How to Use Claude for Product Design: A Practical Workflow
Claude, made by Anthropic, has become a real part of how I work. Not for pixels. For the parts of design that are made of language and judgment, which is where most of the leverage is anyway.
Here is the workflow I actually use, as someone who designs and also writes the code.
Synthesising research
Paste in raw interview notes, survey responses or support tickets and ask for themes, ranked by frequency, with the strongest quote for each. Ask it to flag contradictions too, because those are the interesting part and they are easy to miss by hand.
This turns days of synthesis into minutes. It is the single highest return use I have found.
Writing microcopy
Button labels, empty states, error messages, onboarding. Give it the context and the user's emotional state, then ask for three options at different tones.
Then narrow. Make the error message reassuring rather than blaming, and keep it under twelve words. The second instruction is where the quality comes from.
Critique
Describe a flow, or paste the steps, and ask it to find the holes. Where will people get confused, what is the riskiest assumption in this, what edge case is missing.
Use a capable model here. An Opus family model, currently Claude Opus 5, will actually push back instead of agreeing with you, and agreement is worth nothing in a critique.
Documenting a design system
This is the work nobody wants to do and it is the reason design systems rot. Paste in the components and ask for consistent usage guidance, the cases where a component does not apply, and the accessibility notes.
It will not produce the decisions. It will produce a readable record of decisions you already made, which is the part that keeps getting skipped.
Talking to engineering
Because I write code, I use it to think about feasibility. What a design will actually cost to build. Where the edge cases hide. How to explain a design decision to an engineer in terms they will find reasonable rather than aesthetic.
What makes the difference
- Give it context and intent, not just a task. Who the user is, what the business needs.
- Ask for options and tradeoffs. A single confident answer is usually the least useful output.
- Use a capable model for critique and reasoning, and a faster one for quick drafts. Sonnet is fine for the second kind.
- Treat everything as a strong first draft. Your taste is the part that is not automatable, so spend it there.
Questions I get asked
Can it design a UI? Not well, and I would not ask it to. It is for the thinking, writing and critique around the design. Pair it with your actual design tools.
Which model? An Opus family model for critique and reasoning, a Sonnet model for everyday speed.
Is it better than the alternatives for design? It is particularly good at language, judgment and structured thinking, which is the upstream half of design where the decisions get made. For image work I use something else.