How to write prompts for Claude: 6 templates for designers

Writing a prompt for Claude is like briefing a sharp colleague on their first day. State the context, the task, the material to work from, and the shape of the answer you want: a table or prose, how long, and for which reader. Below is how each part works, followed by six templates designers can paste straight in.

I'm Hai Le, a UI/UX designer who codes. I built this site with Claude Code, and its repo holds a whole folder of plans drafted back and forth with Claude. The principles here come from Anthropic's prompting docs, checked on 2026-10-04. The six templates are scaffolds I wrote for tasks from my own design work. Output depends heavily on the material you feed in, so treat them as starting points and adjust. If you've never opened Claude, start with What is Claude.

What goes into a good prompt?

Anthropic's guide stresses three things that map well to design work:

• Explain why. Telling Claude the reason behind an instruction helps it aim. "Keep it short" is weaker than "keep it short because this label sits on a 120px button".
• Say what to do, not what to avoid. Replace "don't use bullet points" with "write in flowing paragraphs".
• Separate material from instructions. Wrap content in tags like <transcript> or <brief>. For long documents, put the material at the top and the question at the end.

Before sending, I run the test Anthropic suggests: would a colleague with no context be able to follow this? If they'd need to ask questions, Claude will have to guess.

Template 1: How do I synthesize user interviews?

I'm a product designer. I just ran user interviews for [product] to understand [research goal]. The synthesis goes to a meeting with our PM and engineers, so every finding must trace back to something a participant said.

The notes are inside <transcript>. Participants are already anonymized as P1, P2, and so on.

<transcript>
[paste notes]
</transcript>

Work in this order:
1. Quote, verbatim, every passage relevant to [research goal], labeled with the participant.
2. Group the quotes into themes. Count how many participants mention each theme.
3. Return a table: Theme | Participants | Representative quote | Open question.
If a theme comes from only one participant, keep it and mark it "weak signal".

Why it works: step 1 is the "quote first, then work" technique from Anthropic's guide. The quotes give you evidence to audit, and a finding with no quote behind it stands out immediately. The participant count stops one loud voice from becoming "users want". When we tested the Q&A prototype at Oreka, we had five buyers and five sellers. With a sample that small I used the results to find friction, which is what the "weak signal" label is for.

Template 2: How do I write microcopy for an error state?

I need microcopy for an error state in the [flow name] flow of [product]. The user is at [step] and just hit this error: [technical description].

Constraints:
- Title of [number] characters max, because the container fits one line on a 360px screen.
- Body says what happened and what the user can do next.
- Primary button label is a verb.
- Voice: [describe, e.g. calm, second person].

Give me 3 options that take different approaches. For each, show the title's character count and one sentence on when it fits best.

Why it works: every constraint carries its reason (one line, 360px), so Claude knows why brevity matters. Three distinct options give you something to choose between. The character counts help you filter quickly, but recount them yourself, since they can be off. My Oreka QR payment case has a full section on what happens when a transfer doesn't match. That's the kind of screen this template is for.

Template 3: How do I get a heuristic review of a screen?

Attached is a screenshot of [screen name] in [product]. The primary user is [description], and their goal on this screen is [goal].

Review the screen against Nielsen's 10 usability heuristics. For each issue:
- Point to its exact location (area, visible label).
- Name the heuristic it violates.
- Severity from 1 (cosmetic) to 4 (blocks the task), with a reason.
- One direction for a fix.

Return a table sorted by severity, highest first. Only list issues visible in the screenshot. Put anything that needs data or device testing to confirm in a separate "Needs checking" section.

Why it works: the heuristics give the output names you can compare against your own review. Requiring a location lets you verify each row on the image. The "Needs checking" section separates what Claude can see from what it's guessing. On Car From Japan there was no time for full research, so I ran a heuristic review myself and found five problems in the old form. If I did it again today, I'd still do my own pass first, then use this template as a second reviewer to compare against.

Template 4: How do I turn a brief into a handoff checklist?

<brief>
[paste the PM's or client's brief]
</brief>

I'm the designer who received this brief. Turn it into a checklist I can use to check my work before handing designs to engineering.

1. List every requirement in the brief, one per line, with the original sentence in quotes.
2. For each requirement, write a pass/fail criterion I can answer by looking at the design file.
3. Separately, list what the brief doesn't cover: empty, error and loading states, permissions, small screens. Phrase these as questions I can send back to the PM.

Why it works: the brief sits at the top and the instructions follow, the order Anthropic recommends for long material. Quoting the source sentence shows you which lines Claude added on its own. Step 3 is the part I find most useful, because the states a brief forgets usually surface only when an engineer asks.

Template 5: How do I name color tokens consistently?

I'm building a design system with three layers of color tokens:
- Layer 0 (raw): values only, e.g. --gray-600.
- Layer 1 (alias): scales with a role, e.g. neutral-700, primary-700.
- Layer 2 (semantic): named by purpose, e.g. background, foreground, muted-foreground, border.
Components may only use layer 2.

Here are the colors currently used in the Figma file, with where they appear:
[paste list: hex value, usage]

Propose names for all three layers. Return a table: Hex | Layer 0 | Layer 1 | Layer 2 | Reason.
If two colors differ only slightly and serve the same purpose, propose merging them and say so.
If a color has no clear role, write "needs a decision" instead of inventing a name.

Why it works: the template hands over the naming convention with real examples, so Claude doesn't invent its own scheme. This is the same three-layer structure I use for this site, documented in its AGENTS.md. The last line gives Claude a legitimate way out when information is missing. To go further, write the convention into a file as described in What is DESIGN.md, or pull variables straight from Figma with Figma MCP and Claude Code.

Template 6: How do I write release notes from a change list?

Write release notes for version [number] of [product]. The readers are [end users / support team / enterprise customers]. They need to know what changed for them and whether they have to do anything.

Change list from engineering:
<changes>
[paste tickets or commits]
</changes>

One entry in the voice I want:
<example>
Saved filters: you can now save the filters you use most and reopen them in one tap. No action needed.
</example>

Rules:
- Group under New, Improved, Fixed.
- Leave out internal changes with no user impact, and list them separately at the end so I can check.
- One sentence per entry, starting with the feature name.

Why it works: one concrete example sets the voice better than any adjective. Anthropic calls this few-shot prompting and suggests 3 to 5 examples when you need consistency. The list of excluded changes at the end lets you catch anything important that was dropped.

What do I do when the output is off?

1. Don't start over. Name the problem: "item 3 merges two different issues, split them".
2. Ask what's missing. "What information would help you do this better?" often surfaces the context you forgot.
3. Fix the template. When the same correction keeps coming up, move it into the template or into a Project's instructions.

The lesson I remember best came from this site. The mobile menu once opened a language dropdown on top of itself. Claude built exactly what I described, and the description was wrong. A prompt is a brief, and bad output usually starts there.

What should I read next?

• What is Claude? A guide for people who have never used AI: plans, features, privacy.
• Claude Code for designers: when prompts turn into real code.
• Install Claude Code and run your first session.

More on how I work is on my about page.

Sources

Checked on 2026-10-04.

• Claude Docs: Prompting best practices: the new-employee framing and colleague test, explaining why, 3 to 5 examples, XML tags, long material at the top, quoting before working, saying what to do instead of what not to do.
• Claude Docs: Prompt engineering overview.
• Claude Blog: Best practices for prompt engineering.
• Claude Help Center: What are projects?: project instructions and knowledge.
• Nielsen Norman Group: 10 Usability Heuristics for User Interface Design.