Key Takeaways
- Claude can generate a complete, structured design brief from a rough product description in seconds, saving hours of discovery work.
- UX copy prompts work best when you give Claude the button context, the user’s emotional state, and the page goal all at once.
- User persona prompts should include demographic details, pain points, and behavioral cues to get research-quality output.
- Claude produces actionable accessibility notes for UI components when you specify the WCAG standard you are targeting.
- Component documentation prompts are more useful when you describe the component’s purpose, props, and usage restrictions upfront.
- Heuristic review checklists from Claude can be tailored to specific platforms like mobile apps, SaaS dashboards, or e-commerce flows.
- Error messages and empty states require tone guidance in the prompt; tell Claude the product’s voice before asking it to write copy.
Most designers who use Claude for design work are leaving the majority of its capability on the table. They type a vague request, get a mediocre result, and conclude that AI is not useful for design tasks. The real issue is almost always the prompt. Claude is exceptionally good at producing structured, audience-aware design output, but it needs context that most people forget to provide.
This article gives you seven ready-to-use prompts that cover the most common design writing tasks: from writing a proper brief to drafting microcopy that matches your product’s voice. Each prompt is built around a specific use case, includes the actual text you can copy into Claude right now, and comes with tips for adapting it to your project. Whether you are a product designer, a UX writer, or a developer who needs to write decent copy, these prompts will get you to a usable first draft faster than starting from scratch.
Before we get into the prompts, a quick note on how Claude handles design tasks. Claude processes instructions with a strong grasp of document structure and professional writing conventions. It responds well to role framing, output format instructions, and constraint lists. The prompts below are built on those strengths. If you want a broader look at how Claude compares to other models for writing tasks, the Claude vs ChatGPT comparison is a useful starting point.
Prompt 1: Writing a Design Brief from a Product Description
A design brief is one of the most time-consuming documents in any design process. You need to capture the product’s purpose, the target audience, the business goals, the constraints, and the success criteria, all in a format that a designer, a developer, and a stakeholder can each read and agree on. Writing one from scratch takes hours. Writing a bad one costs even more time later when the team is misaligned.
This prompt gives Claude the raw product description and asks it to produce a structured brief. The key to making it work is giving Claude enough raw material: who the product is for, what problem it solves, what platform it lives on, and what the most important outcome is. Claude will organize that information into clearly labeled sections with actionable language.
The prompt works because Claude is trained on a large volume of professional documents and understands that a brief must balance specificity with flexibility. It knows that a good brief answers “what are we making and why” before it touches “how do we make it.” You get a document you can actually hand to a team.
You are a senior UX strategist. Based on the product description below, write a structured design brief. Include these sections: Project Overview, Target Audience, Business Goals, User Goals, Scope and Deliverables, Design Constraints, Success Metrics, and Timeline Assumptions. Use plain language. Be specific. Avoid generic statements like “create a good user experience.” Each section should be 2-4 sentences or a short bullet list.
Product description: [paste your product description here]
Expected output: A multi-section brief document with labeled headings, plain-language descriptions in each section, and concrete success metrics. Claude will typically produce 400-600 words of structured content that reads like a professionally written brief rather than a template filled with placeholder text.
Tips for customizing: If your brief needs to go to a non-technical audience, add “avoid jargon and technical terms” to the instruction. If you are working on a redesign rather than a new product, add “This is a redesign of an existing product. Acknowledge the legacy constraints.” You can also ask Claude to add a “Risks and Assumptions” section by including it in the section list.
Prompt 2: Generating UX Copy Variations for a CTA Button
Button copy is deceptively hard. A single button can carry the weight of the entire conversion flow, and the difference between “Submit” and “Get my free report” is not cosmetic, it is functional. Most teams default to generic labels because writing good CTA copy requires understanding the user’s mental state at the exact moment they see the button, the action they are being asked to take, and the value they will receive after clicking.
Claude handles this well because it can hold multiple constraints in mind simultaneously: the desired action, the product voice, the page context, and the user’s motivation. This prompt asks Claude to produce multiple variations at different tonal registers so you can test them or pick the one that fits your design direction.
The prompt structure forces Claude to think about the user’s perspective rather than the company’s perspective, which is the most common mistake in CTA writing. “Buy now” is company-centric. “Start my free trial” is user-centric. Claude knows the difference when you frame the prompt correctly.
You are a UX writer specializing in conversion copy. Write 8 variations of button copy for the CTA described below. Group the variations into three tonal categories: Direct and Action-Oriented, Benefit-Focused, and Low-Commitment/Low-Pressure. For each variation, write the button label (maximum 5 words) and one sentence explaining why it works psychologically. Do not use exclamation marks.
CTA context: [describe the page, the user’s goal, what happens after they click, and the product’s voice/tone]
Expected output: Eight button copy options organized into three labeled groups, each with a short rationale. This gives you copy you can drop into a design file and reasoning you can use to justify your choice in a stakeholder review.
Tips for customizing: Add “The product targets [age group/industry/persona]” to get vocabulary that matches your audience. If you need copy for a high-stakes action like a payment or a data deletion, add “The user may feel anxious about this action. Write copy that reduces friction and builds trust.” You can also ask for character counts if your button has a fixed width constraint.
Prompt 3: Creating a User Persona from a Target Audience Description
User personas live and die by specificity. A persona that says “Sarah, 34, likes technology” is useless. A persona that describes Sarah’s Monday morning routine, her frustration with her current tool, the workaround she built in a spreadsheet, and the one thing she would pay to never deal with again, that is a persona a design team can actually use.
Claude can produce that level of detail if you give it enough raw material about the target audience. This prompt works by asking Claude to infer behavioral and emotional details from the demographic and psychographic information you provide. It produces a persona that reads like it came from qualitative user research, not from a slide deck template.
The reason this works is that Claude has absorbed patterns from user research reports, customer interview summaries, and product case studies. It understands that personas need to capture goals, frustrations, and decision-making triggers, not just age and job title.
You are a UX researcher. Create a detailed user persona based on the target audience description below. The persona should include: a realistic name and photo description, demographic profile, job context and daily work routine, primary goals related to this product, top 3 frustrations with current solutions, quote that captures their mindset, preferred communication channels, technical proficiency level, and decision-making triggers. Write in third person. Be specific and concrete. Avoid vague generalizations.
Target audience description: [describe your target user including role, industry, goals, and any research data you have]
Expected output: A fully structured persona document with labeled sections, realistic narrative details, a representative direct quote, and behavioral attributes that a designer can reference during the design process. The output typically runs 300-500 words.
Tips for customizing: Add “This persona represents a user who is switching from [competitor product]” to get frustration details that are specific to migration scenarios. If you have actual research data like survey results or interview notes, paste them into the prompt after the audience description and tell Claude to use them as the factual foundation. You can also request multiple personas by asking for “three personas across this audience spectrum: early adopter, mainstream user, and reluctant adopter.”
Prompt 4: Writing Accessibility Notes for a UI Component
Accessibility documentation is one of the most neglected parts of design systems. Designers know they should include it, but writing WCAG-compliant notes for every component is time-consuming and requires a level of technical knowledge that not every designer has. The result is that accessibility notes either get skipped entirely or are written at a level of vagueness that makes them useless to developers.
Claude knows WCAG 2.1 guidelines well and can produce detailed, implementation-ready accessibility notes when you describe a component clearly. This prompt asks for notes that are specific enough for a developer to act on, not just a checklist of generic principles.
The prompt works because it frames the task as producing developer-facing documentation. When you tell Claude who will read the output and what they need to do with it, the output becomes actionable rather than theoretical. A developer reading the notes should be able to implement them without needing to look anything up.
You are an accessibility specialist writing documentation for a design system. Write comprehensive accessibility notes for the UI component described below. Cover these areas: keyboard navigation requirements, ARIA roles and attributes needed, focus management behavior, color contrast requirements (cite WCAG 2.1 AA standards), screen reader announcements, touch target size requirements for mobile, and any known accessibility failure patterns to avoid. Format as a numbered list under each category heading. Write for a developer audience.
Component description: [describe the component, its states, its interactive elements, and its context in the UI]
Expected output: A structured accessibility document with categorized notes, specific ARIA attribute names, WCAG criterion references, and concrete implementation instructions. The notes are detailed enough to be included directly in a design system’s component documentation page.
Tips for customizing: If you need AAA compliance rather than AA, specify that in the prompt. If the component has multiple states (default, hover, focus, disabled, error), list them in your component description so Claude addresses each one. You can also add “Flag any areas where the accessibility requirement conflicts with the visual design” to surface potential design-development tension early.
Prompt 5: Generating Component Documentation for a Design System
Design system documentation has a specific audience with specific needs. A developer using your component library needs to know what a component does, when to use it, when not to use it, what props or variants it accepts, and what the expected behavior is in edge cases. Writing that documentation for every component is one of the biggest bottlenecks in design system maintenance.
This prompt turns a component description into a complete documentation entry. Claude understands the conventions of design system documentation because it has processed documentation from systems like Material Design, Polaris, and Atlassian Design System. It knows the difference between a usage guideline and a technical specification, and it structures the output accordingly.
The key to getting good output is describing the component in terms of its behavior and purpose, not just its visual appearance. Tell Claude what the component is for, what decisions it encodes, and what problems it solves for the user.
You are a design systems specialist writing component documentation. Write a complete documentation entry for the component described below. Include these sections: Component Overview (2-3 sentences), When to Use (3-5 bullet points), When Not to Use (2-4 bullet points), Variants and States (describe each with a one-line explanation), Props or Design Tokens (table format with name, type, default value, and description), Accessibility Notes (3-5 key points), and Related Components (list with one-line relationship description). Write for a mixed audience of designers and developers.
Component description: [describe the component including its name, purpose, interactive behavior, visual variants, and any design decisions baked into it]
Expected output: A complete documentation entry formatted with clear section headings, scannable bullet lists, and a props table. The output follows the structure used by major design systems and can be copied directly into a documentation site with minimal editing.
Tips for customizing: If your design system uses a specific token naming convention, include an example in the prompt so Claude matches your system’s vocabulary. Add “This component replaces [legacy component name]” if you are documenting a migration and need deprecation notes. You can also ask for a “Code snippet placeholder” section if your documentation site includes implementation examples.
Prompt 6: Creating a Usability Heuristic Review Checklist
Nielsen’s 10 usability heuristics are well known, but applying them to a specific product requires translation work. “Visibility of system status” means something different on a mobile banking app than it does on a project management tool. Generic heuristic checklists are easy to find online. A checklist tailored to your specific product type, platform, and user context is much harder to produce and much more valuable in a review session.
Claude can generate that tailored checklist quickly. This prompt asks Claude to apply heuristic principles to your specific product context and produce review questions that are specific enough to catch real usability problems, not just confirm that your design has a loading spinner somewhere.
The prompt works by giving Claude the product type, the primary user task, and the platform, then asking it to write heuristic review questions that are grounded in those specifics. A reviewer working through this checklist should be prompted to notice things they would miss with a generic checklist.
You are a usability expert conducting a heuristic evaluation. Create a usability review checklist for the product described below. Base the checklist on Nielsen’s 10 usability heuristics but write every question in terms of this specific product’s context. For each heuristic, write 3-5 specific review questions that a reviewer could answer with a yes, no, or partial observation. After each question, add a one-line note explaining what to look for. Format as a numbered list under each heuristic heading.
Product context: [describe the product type, the primary user task, the platform (web, mobile, desktop), and the user’s level of technical proficiency]
Expected output: A structured checklist with ten heuristic sections, 3-5 specific review questions per section, and observational guidance for each question. The checklist is specific enough to use in an actual review session and can be converted into a scoring rubric by adding a rating scale.
Tips for customizing: Add “Focus especially on heuristics 1, 5, and 9 as these are the most common failure areas for this product type” to direct Claude’s attention to the heuristics most relevant to your context. If you are reviewing a redesign, add “The product is a redesign. Flag any questions that should specifically check for regressions from the previous version.” You can also ask for a severity rating scale to attach to each question.
Prompt 7: Writing Error Messages and Empty States for a Web App
Error messages are a product’s worst moment. Something has gone wrong, the user is frustrated or confused, and the copy on the screen is either going to rebuild their confidence or make them close the tab. Most error messages are written by developers at 11pm before a deadline, and it shows. “Something went wrong. Please try again” is not a helpful message. It does not tell the user what went wrong, what they can do about it, or whether their data is safe.
Empty states are the opposite problem. They appear when nothing has gone wrong, but the user has not yet done anything meaningful. A well-written empty state is a micro-onboarding moment. A poorly written one feels like a dead end.
Claude produces excellent error copy and empty state copy when you give it the product’s voice, the specific error scenario, and a clear instruction about what information the message must convey. This prompt handles both in a single pass.
You are a UX writer for a web application. Write error messages and empty state copy for the scenarios listed below. For each error message, write: a headline (maximum 8 words), a body message (maximum 2 sentences) that explains what happened and what the user can do next, and a CTA label if one is appropriate. For each empty state, write: a headline, a supporting sentence that explains the benefit of taking action, and a CTA label. Match the tone described. Do not use technical jargon. Do not blame the user.
Product voice: [describe the tone: e.g., friendly and direct, professional and calm, playful and informal]
Scenarios to cover: [list each error or empty state scenario, e.g., “404 page,” “form validation error,” “empty inbox,” “no search results,” “payment failed,” “session expired”]
Expected output: A set of copy blocks, one per scenario, each with a labeled headline, body text, and CTA label. The messages are written in the product’s voice, follow plain language principles, and provide the user with a clear next action rather than a dead end.
Tips for customizing: The more scenarios you list, the more useful the output. Aim to include at least 6-8 scenarios per prompt run. If the product handles sensitive data (health information, financial data), add “The user may be anxious about data security. Reassure without being condescending.” You can also ask Claude to write a “friendly” version and a “formal” version of each message if you have not finalized your brand voice yet.
How to Get Better Results from Claude for Design
The prompts above are starting points, not fixed scripts. Claude responds well to iteration, and the best results usually come from a second or third pass where you refine the output based on what the first draft got right and what it missed. Here are the principles that will improve your results across all design prompts.
Give Claude a role before you give it a task. Starting a prompt with “You are a senior UX designer” or “You are a UX writer specializing in SaaS products” shifts the vocabulary, the level of detail, and the professional assumptions in the output. Claude adjusts its frame of reference based on role framing, and for design tasks this makes a real difference.
Specify the output format explicitly. If you need bullet points, say so. If you need a table, say so. If you need sections with headings, list the headings you want. Claude will choose a format on its own, but it will often choose a prose format when a structured format would serve you better. Telling Claude exactly what structure you need produces output that is closer to usable on the first pass.
Add constraints to reduce generic output. Generic prompts produce generic output. The more constraints you add, the more specific the result. “Do not use corporate jargon,” “avoid passive voice,” “each bullet must be a complete sentence,” “no more than 15 words per headline” – these constraints push Claude toward the kind of precise, professional writing that design work requires.
Include context about the user. Claude writes better design copy when it knows who the user is and what emotional state they are likely in. “The user is a first-time visitor who is skeptical about the product” produces different copy than “the user is a returning customer completing a routine task.” Persona context matters even when you are not writing a persona document.
Iterate in the same conversation. Claude retains context within a conversation thread. If the first output is 80% right, ask Claude to revise specific sections rather than starting a new prompt. “The tone in section 3 is too formal. Rewrite it to match the friendly tone in section 1” is a more efficient path to a good result than rewriting the entire prompt from scratch.
For a broader view of Claude’s capabilities compared to other models, the ChatGPT vs Claude comparison covers how the models differ across writing and reasoning tasks.
Claude Design Prompts vs ChatGPT Prompts
Claude and ChatGPT both handle design writing tasks well, but they have different strengths that matter depending on the task type. Claude tends to produce longer, more structured output on the first pass and follows multi-part instructions more reliably. This makes Claude particularly strong for tasks like design briefs, component documentation, and accessibility notes, where the output needs to be organized and complete rather than just correct.
ChatGPT’s strength in design tasks tends to be in short-form copy variations. It is fast at generating CTA options and microcopy alternatives, and its GPT-4 version integrates well with design tools through plugins. For teams already embedded in the OpenAI ecosystem, ChatGPT’s tooling integrations can matter more than the raw output quality difference.
For standalone prompt use without tool integrations, Claude’s ability to follow structured output instructions precisely makes it the better choice for most of the tasks in this article. The design brief prompt, the persona prompt, and the component documentation prompt all require Claude to hold and apply multiple constraints simultaneously. In testing, Claude’s output on these tasks requires less manual cleanup than comparable ChatGPT output. If you want to explore Claude’s full capability profile, the Claude Opus 4.6 review covers performance benchmarks in detail.
Frequently Asked Questions
Can Claude generate actual UI designs or wireframes?
Claude is a text-based model and does not generate visual designs or wireframes directly. However, it can write detailed design specifications, component descriptions, and layout instructions that you can use as a brief for a design tool like Figma or as input for image-generation tools. For visual output, you would need a separate tool alongside Claude.
Which version of Claude works best for design prompts?
Claude Sonnet and Claude Opus both handle the prompts in this article well. Opus tends to produce more nuanced output on complex tasks like accessibility documentation and design system component docs, while Sonnet is faster and sufficient for most copy-writing tasks like CTA variations and error messages. The free tier of Claude.ai uses a capable version that will work for all seven prompts.
Do I need design knowledge to use these prompts effectively?
Some design knowledge helps you evaluate and refine the output, but you do not need a design background to get useful results from these prompts. The prompts are written to supply most of the professional context Claude needs. The more product context you add (audience, platform, tone), the better the output regardless of your design experience level.
Can I use Claude to review an existing design rather than create new content?
Yes, though Claude cannot see images directly in all interface versions. If you describe your design in text (layout structure, interaction patterns, copy choices), Claude can apply heuristic analysis, identify potential usability issues, and suggest improvements. The heuristic checklist prompt in this article is specifically designed for that kind of review task.
How do I handle it when Claude produces output that is too generic?
The most common cause of generic output is a generic prompt. Add more specificity to your product description, include details about the user, and add constraint instructions like “avoid vague statements” or “every point must be specific to this product type.” You can also ask Claude directly: “This output is too generic. What additional context do you need to make it more specific?”
Is Claude good at writing microcopy for forms and onboarding flows?
Claude is strong at form copy and onboarding microcopy, particularly when you give it the form’s purpose, the user’s goal, and the product’s tone. For onboarding flows, it helps to describe each step in the sequence so Claude understands the context a user has when they see each piece of copy. The CTA and error message prompts in this article can be adapted for form and onboarding copy with minimal changes.
Can these prompts be used in a design system workflow?
Yes. The component documentation prompt and the accessibility notes prompt are specifically built for design system use. Teams that manage large component libraries can use these prompts as a documentation scaffold, generating first drafts for each component and then editing for accuracy. This is especially useful when documenting legacy components that were built before documentation practices were established.
Where can I find more information about AI tools for design and writing?
The best AI chatbots ranked list covers a range of tools that are useful for design and content work. It includes capability comparisons that help you decide which model to use for specific task types.
