30 Claude Prompts for UX Designers

You are a senior UX designer mapping a complete user flow as a visual diagram. <context> A feature needs its full flow, including branches and error states, visualized before wireframes get built. </context> <inputs> - Flow goal: [FLOW_GOAL, e.g. complete checkout] - Entry point: [ENTRY_POINT] - User type: [USER_TYPE] - Known decision points or branches: [BRANCHES] </inputs> <task> Build the flow as a live HTML artifact: boxes for each screen or action connected by arrows, with decision points as diamonds, color-coded by outcome (success, error, abandon). </task> <constraints> - Every branch must reconnect to a labeled end state. - Include at least one error or empty state branch, not just the happy path. - Use inline CSS only, no external libraries, so the artifact renders standalone. </constraints> <format> Return a single self-contained HTML file (inline CSS, no external requests) rendering the flow as a visual diagram. </format>

You are a senior UX designer building a visual journey map from research notes. <context> Raw research notes or interview quotes need to become a visual journey map that shows where users struggle, for a workshop wall or stakeholder deck. </context> <inputs> - Journey stages: [STAGES, e.g. Discover, Sign up, Onboard, First use, Renew] - Research notes or quotes: [RESEARCH_NOTES] - Persona this journey belongs to: [PERSONA] </inputs> <task> Build a live HTML artifact showing a horizontal journey map: one column per stage, with rows for user actions, thoughts, an emotion curve drawn across low to high friction, and pain points quoted from the notes. </task> <constraints> - Every pain point must trace back to something in the provided research notes, not be invented. - The emotion curve must visually dip or rise per stage, not stay flat. - Use inline CSS/SVG only, no external chart libraries. </constraints> <format> Return a single self-contained HTML file with the journey map and emotion curve rendered visually. </format>

You are a senior UX designer justifying a flow redesign to stakeholders. <context> A redesign proposal needs a side-by-side comparison showing exactly what's improving in the task flow, in terms stakeholders can evaluate quickly. </context> <inputs> - Current flow steps: [CURRENT_FLOW] - Proposed flow steps: [PROPOSED_FLOW] - Metric this redesign targets: [TARGET_METRIC, e.g. clicks to complete] </inputs> <task> Compare the current and proposed flows step by step, count total steps and clicks for each, and state the expected improvement on the target metric with reasoning. </task> <constraints> - Step and click counts must be computed from the actual lists provided, not estimated. - If the proposed flow adds a step anywhere, justify why it's still an improvement. - Expected improvement must reference the specific target metric, not a vague claim. </constraints> <format> Return two numbered lists (Current, Proposed) with a step/click count under each, followed by an Expected Improvement paragraph. </format>

You are a senior UX designer diagnosing and redesigning a new user onboarding flow. <context> Analytics show a specific step where new users abandon onboarding, and the redesign needs to address that step directly instead of reworking the whole flow. </context> <inputs> - Current flow steps: [CURRENT_FLOW] - Drop-off step and rate: [DROPOFF_DATA] - Session recording or support ticket observations: [OBSERVATIONS] - Constraint on what can change: [CONSTRAINTS, e.g. cannot remove the payment step] </inputs> <task> Propose a redesigned flow that addresses the drop-off step specifically, listing each screen, what changed from the current flow and why, tying each change back to an observation, and what stays the same due to the stated constraints. </task> <constraints> - The screen at or before the drop-off point must have a specific, named change tied to an observation, not a general note to simplify. - Respect every stated constraint explicitly. - List the current and proposed step count so the change is visible. </constraints> <format> Return a table: Step, Current, Proposed Change, Tied-to Observation, followed by a Step Count Before/After line. </format>

You are a senior UX designer building a service blueprint that includes backstage operations. <context> A journey map alone doesn't show what staff or systems do behind the scenes to support each user-facing step, and the team needs that visibility to spot operational risk. </context> <inputs> - Front-stage user steps: [USER_STEPS] - Backstage actions or systems involved: [BACKSTAGE_ACTIONS] - Support channels involved: [SUPPORT_CHANNELS] </inputs> <task> Build a service blueprint table with rows for Front-stage (user-visible) actions, Backstage actions, Support systems involved, and Failure risk per step. </task> <constraints> - Every front-stage step must have at least one corresponding backstage row, even if it's marked as none identified. - Failure risk must be rated High/Medium/Low with a one-line reason, not left blank. - Do not invent backstage systems not mentioned in the inputs, mark unknowns as needing input from ops. </constraints> <format> Return a table: Front-stage Step, Backstage Action, Support System, Failure Risk, followed by a list of flagged gaps. </format>

You are a senior UX researcher writing up usability test results for the team. <context> A round of usability testing just wrapped, and raw session notes need to become a findings report the team can act on. </context> <inputs> - Number of participants: [PARTICIPANT_COUNT] - Task(s) tested: [TASKS] - Raw observations or notes per session: [SESSION_NOTES] </inputs> <task> Synthesize the session notes into findings, each with a severity rating (Critical, Serious, Minor, Cosmetic), how many of the tested participants hit it, a direct quote or observation as evidence, and a recommended fix. </task> <constraints> - Every finding must cite how many participants experienced it, not a vague reference to some users. - Severity ratings must follow the stated scale consistently, Critical means the task could not be completed. - Do not merge two unrelated issues into one finding just to shorten the list. </constraints> <format> Return a table: Finding, Severity, Participants Affected, Evidence, Recommended Fix, sorted by severity. </format>

You are a senior UX researcher clustering raw usability test notes into themes. <context> Multiple sessions produced a pile of scattered, sticky-note-style observations that need to be grouped into themes before they can become findings. </context> <inputs> - Raw observations (one per line, unsorted): [RAW_NOTES] - Task these observations relate to: [TASK] </inputs> <task> Group the raw observations into 4 to 8 themes, name each theme descriptively, list which raw notes belong to it, and count how many notes support each theme. </task> <constraints> - Every raw note provided must be assigned to exactly one theme, none dropped or duplicated. - Theme names must describe the underlying issue, not the task itself, for example unclear pricing labels rather than pricing page. - Sort themes by note count, highest first. </constraints> <format> Return a list of themes, each with its note count and the raw notes clustered underneath it, sorted by count descending. </format>

You are a senior UX researcher triaging issues observed across usability test recordings. <context> A team needs a prioritized, bug-style list from usability testing, formatted so it can be dropped straight into a ticket tracker. </context> <inputs> - Observed issues (one per line): [OBSERVED_ISSUES] - Which task/screen each occurred on: [TASK_SCREEN_MAP] - Business priority context: [PRIORITY_CONTEXT, e.g. checkout issues are highest priority this quarter] </inputs> <task> Convert each observed issue into a ticket-style row: title, screen, severity (Critical/Serious/Minor/Cosmetic), suggested owner (design/engineering/content), and priority rank given the business context. </task> <constraints> - Severity must reflect task completion impact, not annoyance level alone. - Priority rank must weight issues on screens named in the business priority context higher. - Every row needs a suggested owner, never leave it blank. </constraints> <format> Return a table: Title, Screen, Severity, Owner, Priority Rank, sorted by priority rank. </format>

You are a senior UX researcher translating an A/B test result into a stakeholder-ready readout. <context> An A/B test finished with a statistical result that needs translating into a plain-language recommendation for people who don't work with confidence intervals daily. </context> <inputs> - Metric tested: [METRIC] - Variant A result: [VARIANT_A_RESULT] - Variant B result: [VARIANT_B_RESULT] - Statistical significance and sample size: [SIGNIFICANCE_DATA] </inputs> <task> Write a plain-language readout stating which variant won, by how much, whether the result is statistically significant given the sample size, and a clear ship, don't ship, or run longer recommendation. </task> <constraints> - If the result is not statistically significant, the recommendation must say so plainly and suggest running longer, never present a shaky result as a clear win. - State the practical effect size in real terms, for example roughly 40 more signups per 1,000 visitors, not just percentage lift. - Do not use statistical jargon without a one-line plain-language translation next to it. </constraints> <format> Return a short readout: Result, Confidence, Practical Impact, Recommendation, each 1 to 2 sentences. </format>

You are a senior UX researcher summarizing accessibility-related usability findings. <context> Testing included participants using assistive technology or accessibility settings, and the findings need to be separated out so they don't get lost in the general report. </context> <inputs> - Assistive tech or settings used by participants: [ASSISTIVE_TECH] - Observed issues: [OBSERVED_ISSUES] - Relevant WCAG criteria if known: [WCAG_CRITERIA] </inputs> <task> List each accessibility issue observed, the assistive technology it affects, the likely WCAG criterion it relates to, severity, and a recommended fix a designer or engineer can act on. </task> <constraints> - Only cite a WCAG criterion if it plausibly matches the described issue, otherwise state that it needs review by an accessibility specialist. - Every fix must be actionable by design or engineering, not a suggestion to consult a specialist alone. - Flag any issue that would fully block task completion for that assistive tech as Critical. </constraints> <format> Return a table: Issue, Assistive Tech Affected, Likely WCAG Criterion, Severity, Recommended Fix. </format>

You are a senior UX designer building a persona grounded in real research data, not stereotypes. <context> A persona needs to represent a real user segment backed by research data, to keep the team from designing for an imagined average user. </context> <inputs> - Segment name: [SEGMENT_NAME] - Research data or survey results: [RESEARCH_DATA] - Key behaviors observed: [BEHAVIORS] - Top goals and frustrations: [GOALS_FRUSTRATIONS] </inputs> <task> Build a persona as a live HTML artifact: a card with name, role, a short bio grounded in the data, top 3 goals, top 3 frustrations, and a representative quote pulled or paraphrased from the research data. </task> <constraints> - Every goal, frustration, and the quote must trace back to the provided research data, not be invented. - Include a small citation line noting the sample size, for example based on 42 respondents, so the persona doesn't read as fabricated. - Use inline CSS only, no external images or libraries. </constraints> <format> Return a single self-contained HTML file styled as a persona card. </format>

You are a senior UX designer building an empathy map from qualitative research. <context> Before a workshop, the team wants a visual empathy map summarizing what a user segment thinks, feels, says, and does, based on interview data. </context> <inputs> - Segment or persona name: [SEGMENT_NAME] - Interview notes or quotes: [INTERVIEW_NOTES] - Context/situation this applies to: [SITUATION] </inputs> <task> Build a live HTML artifact laid out as a four-quadrant empathy map (Thinks, Feels, Says, Does), each quadrant populated with items pulled from the interview notes, plus a Pains and Gains strip below. </task> <constraints> - Every quadrant item must be traceable to the interview notes, not invented. - Items in the Says quadrant should be close to direct quotes; items in Thinks and Feels can be reasonable inference, labeled as such. - Use inline CSS/SVG only, no external dependencies. </constraints> <format> Return a single self-contained HTML file rendering the four-quadrant empathy map plus Pains/Gains strip. </format>

You are a senior UX designer writing Jobs-to-be-Done statements from research data. <context> The team wants to reframe user needs as Jobs-to-be-Done statements to avoid designing around demographics instead of underlying motivation. </context> <inputs> - Segment: [SEGMENT_NAME] - Observed behaviors and quotes: [BEHAVIORS_QUOTES] - Situation/trigger context: [TRIGGER_CONTEXT] </inputs> <task> Write 5 to 8 Jobs-to-be-Done statements in the format When [situation], I want to [motivation], so I can [expected outcome], each grounded in a specific observed behavior or quote. </task> <constraints> - Every statement must cite which behavior or quote it's grounded in, in a parenthetical note. - No statement should name a specific feature or solution, only the underlying need. - Remove near-duplicate statements, merge instead of listing twice. </constraints> <format> Return a numbered list of JTBD statements, each with a source citation in parentheses. </format>

You are a senior UX designer comparing user segments to decide who to design for first. <context> Multiple user segments exist and the team needs a side-by-side comparison to prioritize which one to design for in the next release. </context> <inputs> - Segments to compare: [SEGMENT_LIST] - Data available per segment (size, behavior, value): [SEGMENT_DATA] - Business goal this release should serve: [BUSINESS_GOAL] </inputs> <task> Build a comparison table across segments with rows for size, key behavior, primary need, and fit with the stated business goal, then recommend one segment to prioritize with reasoning. </task> <constraints> - The recommendation must reference specific data from the table, not just assert a preference. - If two segments tie on fit, say so explicitly rather than forcing a false distinction. - Do not recommend a segment with no data provided, flag it as needing research first. </constraints> <format> Return a table: Segment, Size, Key Behavior, Primary Need, Fit With Goal, followed by a Recommendation paragraph. </format>

You are a senior UX designer defining who a product is deliberately not designing for. <context> Scope keeps creeping because the team tries to please every possible user. An anti-persona brief makes the deliberate exclusions explicit so future feature requests can be evaluated against it. </context> <inputs> - Product or feature: [PRODUCT_NAME] - Primary persona already defined: [PRIMARY_PERSONA] - User types that keep requesting out-of-scope things: [OUT_OF_SCOPE_REQUESTS] </inputs> <task> Write an anti-persona brief naming 1 to 2 user types the product is not designing for right now, why, based on what conflicting need they have versus the primary persona, and 3 example feature requests that should be declined because they serve the anti-persona instead. </task> <constraints> - The stated conflict must be a real tradeoff where serving the anti-persona would hurt the primary persona, not just a difference in needs. - Every example feature request must be something a stakeholder could plausibly ask for, not a strawman. - Do not describe the anti-persona in dismissive or insulting language, this is a scoping tool, not a judgment. </constraints> <format> Return a short brief: Who, Why Excluded (with the tradeoff named), Example Requests to Decline. </format>

You are a senior UX designer running a heuristic evaluation against Nielsen's 10 usability heuristics. <context> A screen or flow needs a structured expert review before user testing, to catch obvious issues cheaply first. </context> <inputs> - Screen or flow description (or pasted content/copy): [SCREEN_DESCRIPTION] - Specific concerns to focus on, if any: [FOCUS_AREAS] </inputs> <task> Evaluate the screen against each of Nielsen's 10 heuristics, note a specific violation if one exists, or state clearly that no violation was observed, rate severity 0 to 4, and give one concrete fix per violation. </task> <constraints> - Cite the specific element or copy that violates each flagged heuristic, not a general statement. - If a heuristic has no violation, say so explicitly rather than skipping it. - Fixes must be specific enough to hand to a designer directly, for example an exact copy change, not a vague instruction to improve clarity. </constraints> <format> Return a table: Heuristic, Violation Found, Severity (0-4), Specific Fix. </format>

You are a senior UX designer giving structured critique on a teammate's design. <context> A design review needs feedback that's specific and actionable, framed around the user problem rather than personal taste. </context> <inputs> - Design description or screen content: [DESIGN_DESCRIPTION] - Problem this design is meant to solve: [PROBLEM_STATEMENT] - Constraints the designer was working under: [CONSTRAINTS] </inputs> <task> Give critique in three sections: What's working, tied to the problem statement, what's not solving the problem yet, with reasoning, and 2 to 3 specific questions to ask the designer before suggesting fixes. </task> <constraints> - Every critique point must reference the stated problem statement, not a general aesthetic preference. - Respect the stated constraints, don't critique something the designer had no control over. - Frame the gaps section as open questions, not directives, to keep it a discussion rather than a rewrite order. </constraints> <format> Return three headed sections: What's Working, Gaps Against the Problem, Questions to Ask. </format>

You are a senior UX designer running a structured teardown of a competitor product. <context> The team wants to understand a specific flow in a competitor's product deeply enough to borrow good patterns and avoid their mistakes, not just take screenshots. </context> <inputs> - Competitor and flow: [COMPETITOR_FLOW] - What you observed step by step: [OBSERVED_STEPS] - Your own product's equivalent flow, if it exists: [OWN_FLOW] </inputs> <task> Break down the observed flow step by step, noting what works well, what seems intentional versus accidental, and where your own flow could adopt or should explicitly avoid a pattern. </task> <constraints> - Every works-well or avoid-this claim must reference a specific observed step, not a general impression. - If comparing to your own flow, name the specific step it maps to. - Distinguish clearly between what to borrow and what to avoid, don't leave it ambiguous. </constraints> <format> Return a table: Step, Observation, Works Well or Avoid, Note for Own Product. </format>

You are a senior UX designer running a quick accessibility scan on a screen before it goes to development. <context> A full accessibility audit takes too long for every screen, so a fast checklist-based scan catches the common issues early. </context> <inputs> - Screen description including colors, text sizes, and interactive elements: [SCREEN_DESCRIPTION] - Color values used, if known: [COLOR_VALUES] </inputs> <task> Run through a checklist covering color contrast, estimating pass or fail against WCAG AA using the given color values, text sizing, tap target size, focus order, and alt-text presence, marking each pass, fail, or unknown. </task> <constraints> - Mark an item as unknown and needing verification rather than guessing when information wasn't provided. - Every fail needs a specific, minimal fix, for example the exact contrast ratio needed, not a general accessibility lecture. - Do not claim compliance with a specific WCAG level without the data to support it, hedge appropriately. </constraints> <format> Return a checklist table: Item, Status (Pass/Fail/Unknown), Fix if Failed. </format>

You are a senior UX researcher analyzing first-click test results. <context> A first-click test was run on a screen to see where users click first when trying to complete a task, and the raw click data needs interpreting. </context> <inputs> - Task given to participants: [TASK] - Correct or expected element: [EXPECTED_ELEMENT] - Recorded first clicks (element and count): [CLICK_DATA] </inputs> <task> Calculate the percentage of clicks on the correct element versus each incorrect element, identify the top wrong-click destination, and hypothesize why users clicked there instead. </task> <constraints> - Percentages must be computed from the actual click counts provided, not estimated. - The hypothesis for the top wrong click must reference something specific about that element, such as its label, position, or visual weight, not just call it confusing. - State whether the correct-click rate is strong, borderline, or weak using an explicit threshold you name. </constraints> <format> Return a table: Element, Click Count, Percentage, followed by a Top Wrong Click Hypothesis paragraph and a strength verdict. </format>

You are a senior UX designer facilitating a feature prioritization exercise. <context> A backlog of proposed features or fixes needs to be plotted on an impact versus effort grid so the team can agree on what to tackle first. </context> <inputs> - Feature/fix list with your impact and effort estimates (1-5 scale each): [FEATURE_LIST] </inputs> <task> Build a live HTML artifact rendering a 2x2 impact/effort scatter grid, axes labeled, quadrants named Quick Wins, Big Bets, Fill-ins, and Money Pits, plotting each item as a labeled dot positioned by its scores. </task> <constraints> - Dot position must correspond numerically to the given impact/effort scores, not be placed arbitrarily. - Every item must be labeled directly on or next to its dot, not just in a separate legend. - Use inline CSS/SVG only, no external chart libraries. </constraints> <format> Return a single self-contained HTML file rendering the impact/effort grid with all items plotted and labeled. </format>

You are a senior UX designer helping structure a project into a portfolio case study. <context> A finished project needs to become a portfolio case study that shows process and impact, not just final screens. </context> <inputs> - Project name and one-line summary: [PROJECT_SUMMARY] - Problem it solved: [PROBLEM] - Your role and key decisions made: [ROLE_DECISIONS] - Outcome or metrics, if known: [OUTCOME] </inputs> <task> Outline the case study with sections Problem, Your Role, Process (research, key decisions, iterations), Outcome, and a one-line takeaway, each with 2 to 4 bullet points of what to say. </task> <constraints> - The Process section must reference specific decisions from the input, not generic filler about doing research and iterating. - If no outcome metric was given, say so and suggest what to ask a stakeholder for instead of inventing a number. - Keep every section a bulleted outline, not full prose, since this feeds a portfolio deck later. </constraints> <format> Return a headed outline with bullet points per section, ready to expand into slides or a write-up. </format>

You are a senior UX researcher preparing a readout of research findings for stakeholders. <context> A completed research study needs to become a short deck outline that leads with the decision stakeholders need to make, not a chronological retelling of the study. </context> <inputs> - Research question: [RESEARCH_QUESTION] - Key findings (list): [KEY_FINDINGS] - Decision stakeholders need to make: [DECISION_NEEDED] </inputs> <task> Outline a readout deck: a one-slide headline recommendation up front, 3 to 5 supporting finding slides each with the evidence behind it, and a closing slide naming next steps and open questions. </task> <constraints> - The headline recommendation slide must come first, not last, this is a readout, not a slow reveal. - Every finding slide must state the evidence it's based on, not just the conclusion. - Next steps must be specific actions with an owner placeholder, not a vague instruction to continue researching. </constraints> <format> Return a slide-by-slide outline, each slide with a one-line headline and 2 to 3 supporting bullets. </format>

You are a senior UX designer writing a design rationale memo to preempt stakeholder pushback. <context> A design decision is likely to get questioned in review, and a short rationale memo written ahead of time keeps the discussion focused on evidence instead of opinion. </context> <inputs> - Design decision made: [DECISION] - Alternatives considered and why they were rejected: [ALTERNATIVES] - Evidence supporting this decision (research, data, precedent): [EVIDENCE] - Anticipated objection: [ANTICIPATED_OBJECTION] </inputs> <task> Write a short memo stating the decision, the alternatives considered with a one-line reason each was rejected, the evidence supporting the chosen path, and a direct response to the anticipated objection. </task> <constraints> - Every rejected alternative needs a specific reason grounded in the brief or constraints, not a vague preference. - The response to the anticipated objection must engage with it directly, not dodge it with a topic change. - Keep the memo under 300 words so it gets read before the meeting, not during it. </constraints> <format> Return a memo under 300 words with headed sections: Decision, Alternatives Considered, Evidence, Response to Objection. </format>

You are a senior UX designer triaging a backlog of accumulated UX debt. <context> Small usability compromises have piled up over multiple releases, and the team needs a triaged list to argue for dedicated time to fix a subset of them. </context> <inputs> - List of known UX debt items: [DEBT_ITEMS] - User impact data if known (complaints, support tickets, drop-off): [IMPACT_DATA] - Time available to address debt this cycle: [TIME_BUDGET] </inputs> <task> Triage the debt list into a table with user impact rating, estimated fix effort (S/M/L), and a recommendation of which items fit within the stated time budget. </task> <constraints> - Impact rating must reference the provided impact data where available, mark items without data as having unverified impact. - The final recommended set must plausibly fit within the stated time budget, don't recommend more than fits. - Sort the table by impact, highest first, so the argument for prioritization is visible at a glance. </constraints> <format> Return a table: Debt Item, Impact, Effort, Include in This Cycle?, sorted by impact. </format>