30 Claude Prompts for Usability Tests

You are a product researcher who turns fuzzy product hypotheses into observable usability tasks. <context> I have a hypothesis about a flow we just shipped and I need a task that lets me see if people can do the job, not a task that asks them if they like the design. </context> <inputs> - Product hypothesis: [HYPOTHESIS] - User job to be done: [JOB TO BE DONE] - Starting screen: [STARTING SCREEN] - What success looks like: [SUCCESS CRITERIA] - What I must not reveal: [SPOILERS TO AVOID] </inputs> <task> Write one primary task scenario the participant hears, plus two variant wordings if the first one is too leading, and a hidden success definition for the observer. </task> <constraints> The spoken scenario must not name UI labels, buttons, or the feature name. Keep it under 40 words. Success must be a visible end state, not a feeling. Do not include a time limit in the spoken text. </constraints> <format> Three labeled blocks: Spoken scenario, Alternate wordings, Observer success definition. No extra commentary. </format>

You are a UX researcher who tests first-run onboarding before a launch, not after support tickets pile up. <context> We are about to ship a first-run flow and I need a tight task set that covers account start, the first successful action, and the moment people usually get stuck. </context> <inputs> - Product: [PRODUCT NAME] - First-run goal: [FIRST RUN GOAL] - Known friction from analytics: [KNOWN DROP-OFF] - Account state at start: [STARTING ACCOUNT STATE] - Time box: [SESSION LENGTH IN MINUTES] </inputs> <task> Write four first-run tasks in order: arrive and orient, complete the core first action, recover from the known drop-off, and decide what to do next. Give spoken scenario text and observer notes for each. </task> <constraints> Do not walk them through empty states we already know they skip. Keep each spoken scenario under 35 words. The set must fit the time box with two minutes of buffer. No marketing language in the spoken text. </constraints> <format> Numbered tasks 1 to 4, each with Scenario and Observer notes. End with a one-line pass or fail rule for the whole first run. </format>

You are a design researcher who runs within-subject comparisons without tipping which variant is the favorite. <context> I need participants to complete the same job on two design variants so I can compare time, errors, and preference, without the task text favoring one version. </context> <inputs> - Job they must complete: [JOB TO BE DONE] - Variant A description: [VARIANT A] - Variant B description: [VARIANT B] - Order I plan to use: [PRESENTATION ORDER] - Metric I will score: [COMPARISON METRIC] </inputs> <task> Write one shared task scenario that works for both variants, a short orientation line for switching variants, and a post-comparison question set that separates preference from confidence. </task> <constraints> The shared scenario must not mention layout, color, or control names that exist in only one variant. Keep the switch line under 15 words. Do not ask which one looks more modern. Include a counterbalance note for order effects. </constraints> <format> Four labeled blocks: Shared scenario, Switch line, Post-comparison questions, Order note. </format>

You are a usability specialist who tests error recovery, not just happy paths. <context> Our last test stopped when someone failed a step. I want a recovery task I can hand them so I can see whether the product helps them get back on track. </context> <inputs> - Failed step: [FAILED STEP] - Error they would see: [ERROR STATE] - Desired recovery end state: [RECOVERY SUCCESS] - Help content available: [HELP OPTIONS] - What I must not say: [HINTS TO AVOID] </inputs> <task> Write a recovery task that starts from the failed state, a moderator line that acknowledges the fail without fixing it, and three observer codes for how they recover. </task> <constraints> The moderator line must not point at help, settings, or a workaround. Do not reset the task unless they ask. Observer codes must be mutually exclusive: self-recovered, helped by UI, or abandoned. </constraints> <format> Labeled blocks: Recovery scenario, Moderator line, Observer codes with a one-line definition each. </format>

You are a product researcher who maps a whole job-to-be-done onto a usability task path instead of isolated screens. <context> Stakeholders keep asking me to test one screen. I need a task path that follows the real job from trigger to done so we see handoffs, not just a single page. </context> <inputs> - Job to be done: [JOB TO BE DONE] - Trigger that starts the job: [JOB TRIGGER] - Systems they touch: [SYSTEMS OR SURFACES] - Definition of done: [DONE STATE] - Session length: [SESSION LENGTH IN MINUTES] </inputs> <task> Break the job into 3 to 5 sequential tasks that cover trigger, core work, a likely handoff, and done. For each task give spoken text, the surface it starts on, and what done looks like before the next task. </task> <constraints> Do not invent systems that are not in the input list. Keep the path inside the session length with a 5 minute debrief reserved. Spoken text must stay in the participant's words, not our product vocabulary. </constraints> <format> A numbered path. Each item: Task name, Spoken text, Start surface, Done before next. Close with a one-line coverage gap if a system was skipped for time. </format>

You are a UX researcher who turns messy live notes into a finding log a product team can scan the same afternoon. <context> I have raw notes from a usability session and I need them cleaned into findings with evidence, not a recap of everything the person said. </context> <inputs> - Raw notes: [PASTE SESSION NOTES] - Session number: [SESSION NUMBER] - Participant profile: [PARTICIPANT PROFILE] - Tasks they ran: [TASK LIST] - Study goal: [STUDY GOAL] </inputs> <task> Extract findings only. For each finding state the observed behavior, the task it occurred on, a short evidence quote or paraphrase, and whether it blocked the task. </task> <constraints> Do not invent quotes or behaviors that are not in the notes. If a note is an opinion with no observed action, put it in a separate Opinions list. Limit to the 8 strongest findings. No severity ratings yet. </constraints> <format> A table with columns: Finding, Task, Evidence, Blocked yes or no. Then a short Opinions list. No intro paragraph. </format>

You are a research synthesist who clusters usability notes across sessions before anyone picks a favorite anecdote. <context> I finished five sessions and my notes are still per person. I need themes that show what repeated, what was a one-off, and what is still thin. </context> <inputs> - Notes from all sessions: [PASTE ALL SESSION NOTES] - Session count: [SESSION COUNT] - Study goal: [STUDY GOAL] - Themes I already suspect: [SUSPECTED THEMES] </inputs> <task> Cluster the notes into 5 to 7 themes. For each theme give the count of sessions it appeared in, one evidence line per supporting session, and a one-line statement of what is still unknown. </task> <constraints> Do not force my suspected themes if the notes do not support them. Mark a theme as thin if it appeared in only one session. Do not assign severity. Do not recommend solutions yet. </constraints> <format> One headed block per theme: Theme name, Session count, Evidence lines, Still unknown. End with a list of leftover notes that did not fit a theme. </format>

You are a UX writer embedded with research who picks quotes that prove a finding without turning the readout into theater. <context> I have a finding I want to take to stakeholders and I need short quotes or paraphrases from the notes that actually support it, not colorful lines that just sound good. </context> <inputs> - Finding statement: [FINDING STATEMENT] - Source notes or transcript: [PASTE NOTES OR TRANSCRIPT] - Audience for the readout: [STAKEHOLDER AUDIENCE] - Quote length cap: [MAX WORDS PER QUOTE] </inputs> <task> Select up to five quotes or tight paraphrases that support the finding. For each one, state which task or moment it came from and whether it is a direct quote or a paraphrase. </task> <constraints> Reject colorful lines that do not support the finding. Do not clean up grammar if that changes meaning. If fewer than three real supports exist, say the finding is under-evidenced and stop. Honor the word cap. </constraints> <format> A numbered list. Each item: Quote or paraphrase, Source moment, Direct or paraphrase. If under-evidenced, one sentence saying so and what evidence is missing. </format>

You are a research lead who trains teams to separate what people did from what they said they felt. <context> My notes mix clicks, pauses, and opinions in the same bullets. I need them split so we do not treat I like this as evidence the task succeeded. </context> <inputs> - Mixed notes: [PASTE MIXED NOTES] - Tasks in the session: [TASK LIST] - Success definition: [SUCCESS CRITERIA] - Participant profile: [PARTICIPANT PROFILE] </inputs> <task> Split every note into Observed behavior or Opinion. Then mark each observed item as task success, task fail, or not a task event. Call out any place where the opinion contradicts the behavior. </task> <constraints> Do not reword observations into softer language. If a line cannot be classified, put it under Unclear. Do not assign severity. Do not drop contradictions to make the story tidy. </constraints> <format> Three lists: Observed, Opinions, Contradictions. Each observed line ends with Success, Fail, or Not a task event. </format>

You are a UX operations analyst who builds session-by-task matrices so a team can see pattern at a glance. <context> I need a matrix of participants against tasks with a simple outcome code, so we stop arguing from memory about who got stuck where. </context> <inputs> - Session notes for all participants: [PASTE ALL SESSION NOTES] - Task list: [TASK LIST] - Participant IDs: [PARTICIPANT IDS] - Outcome codes I want: [OUTCOME CODES] </inputs> <task> Build a matrix with participants as rows and tasks as columns. Fill each cell with one outcome code plus a 8-word max evidence note. Add a totals row that counts each code per task. </task> <constraints> Use only the outcome codes I provided. If a task was skipped, write SKIPPED, not a guess. Do not add a new code. Evidence notes must point at behavior, not preference. </constraints> <format> A markdown table, then a one-line read of which task has the worst fail count. No other commentary. </format>

You are a UX researcher who rates usability issues with Jakob Nielsen's 0 to 4 severity scale and refuses to inflate scores to get engineering attention. <context> I have a list of issues from a usability study and I need a severity rating for each one that I can defend in a ranking meeting. </context> <inputs> - Issue list: [ISSUE LIST] - Frequency across sessions: [FREQUENCY NOTES] - Impact if it happens: [IMPACT NOTES] - Persistence if they retry: [PERSISTENCE NOTES] - Product context: [PRODUCT NAME AND SURFACE] </inputs> <task> Rate each issue from 0 to 4 using frequency, impact, and persistence. Give a one-sentence rationale that cites those three factors, and name the score in words as well as the number. </task> <constraints> Do not give every issue a 3 or 4. A cosmetic issue is 0 or 1 even if a stakeholder hates it. If frequency data is missing, say so and rate with a confidence tag of low. Do not recommend fixes here. </constraints> <format> A table: Issue, Score, Score name, Rationale, Confidence. Sort highest severity first. </format>

You are a research lead who settles fights when an issue is rare but costly, or common but shallow. <context> My team disagrees on severity because one issue showed up once and blocked the job, and another showed up in every session but people worked around it. I need a written call. </context> <inputs> - Issue A: [RARE HIGH IMPACT ISSUE] - Issue B: [COMMON LOW IMPACT ISSUE] - Session count: [SESSION COUNT] - Who is arguing: [TEAM ROLES IN THE DEBATE] - Decision this rating will drive: [PRODUCT DECISION] </inputs> <task> Write a severity call for each issue, explain how you weighed frequency against impact, and state which issue should be fixed first given the product decision. </task> <constraints> Do not split the difference just to keep peace. If the sample is too small to trust frequency, say that plainly. Keep the whole write-up under 180 words. No sarcasm about either role. </constraints> <format> Three short sections: Issue A call, Issue B call, Fix first. Each section is 3 to 5 sentences. </format>

You are a design operations manager who writes a severity rubric a mixed product squad can apply without a researcher in the room. <context> Engineers, PMs, and designers on my squad rate the same issue differently. I need a one-page rubric with examples from our product so we stop renegotiating the scale every sprint. </context> <inputs> - Product: [PRODUCT NAME] - Scale we want: [SCALE SUCH AS 0 TO 4] - Example issues from last study: [EXAMPLE ISSUES] - Who will use the rubric: [TEAM ROLES] - What a ship-blocking issue means here: [SHIP BLOCK DEFINITION] </inputs> <task> Write a rubric that defines each score in one sentence, gives one example from the issue list per score, and states who may override a score and when. </task> <constraints> Examples must come from the issue list I provided, not generic e-commerce cases. Keep the page under 220 words. Do not invent a score the scale does not include. Avoid words like critical unless they map to a number. </constraints> <format> A score table, then a 4-line override rule, then a 2-line note on what never gets a ship-block score. </format>

You are a product manager who turns a rated issue list into a sprint-sized fix set without pretending every high severity item fits. <context> I have a severity-rated list from a usability study and a sprint that can take a limited amount of design and engineering time. I need a cut that is honest about what waits. </context> <inputs> - Rated issues: [RATED ISSUE LIST] - Sprint capacity: [DESIGN AND ENG CAPACITY] - Already committed work: [COMMITTED WORK] - Launch or milestone date: [MILESTONE DATE] - Non-negotiable legal or safety items: [MUST FIX ITEMS] </inputs> <task> Propose a sprint cut of issues with a one-line reason each, a wait list with the risk of waiting, and any issue that should ship as a guardrail or copy change instead of a full fix. </task> <constraints> Do not exceed stated capacity. Must-fix items go in even if they crowd out a popular cosmetic issue. Do not rename severity to make the cut look tidier. Keep the whole plan under 200 words. </constraints> <format> Three lists: In this sprint, Wait, Smaller change. Each item is one line: issue, severity, reason. </format>

You are a cautious UX researcher who protects the backlog from issues that appeared once and sounded dramatic. <context> One vocal participant had a hard time and the team wants to treat every moment as a high-severity issue. I need a pass that flags likely one-off problems before we file tickets. </context> <inputs> - Issue list: [ISSUE LIST] - Which sessions each issue appeared in: [SESSION MAP] - Participant notes: [PARTICIPANT NOTES] - Sample size: [SESSION COUNT] - Domain experience of each person: [EXPERIENCE LEVELS] </inputs> <task> Mark each issue as Recurring, Needs more evidence, or Likely one-off. For Likely one-off, say why, using session count, experience level, or a unique setup, and give the next cheapest check. </task> <constraints> Do not dismiss a single-session blocker if the sample is three or fewer. Do not use tone or personality as the reason. Next checks must be cheaper than another full study when possible, such as a analytics look or a hallway pass. </constraints> <format> A table: Issue, Mark, Why, Next check. Sort Likely one-off to the top so the team sees what not to file first. </format>

You are a research operations specialist who writes screeners that find the right people without teaching them the answers. <context> I need a screener for an upcoming usability study so recruiters do not send me people who only look like the persona on a job title. </context> <inputs> - Target persona: [TARGET PERSONA] - Must-have behaviors: [MUST HAVE BEHAVIORS] - Disqualifiers: [DISQUALIFIERS] - Product or category: [PRODUCT CATEGORY] - Study format and length: [FORMAT AND LENGTH] </inputs> <task> Write a 8 to 12 question screener with answer options, a clear pass rule for each question, and a final pass or fail rule for the whole screener. </task> <constraints> Do not ask people if they are the persona by name. Mix in two decoy questions so the target answers are not obvious. Keep it under 4 minutes to complete. No open text except one optional comment. </constraints> <format> Numbered questions with options, each followed by PASS or FAIL logic. End with the overall rule in 3 lines. </format>

You are a research operations lead who briefs a panel vendor so the first slate is usable, not a resume dump. <context> I am sending a study to an external recruiter and I need a brief they can act on without a kickoff call, including who to find, who to reject, and what good looks like. </context> <inputs> - Target profile: [TARGET PROFILE] - Sample size and mix: [SAMPLE SIZE AND MIX] - Incentive: [INCENTIVE] - Dates and timezone: [SESSION DATES AND TIMEZONE] - Tool and format: [TOOL AND FORMAT] - Things that failed last time: [PAST RECRUIT PROBLEMS] </inputs> <task> Write a one-page recruitment brief covering profile, quotas, screener use, incentive, schedule windows, and a reject list. Include two example good participants and two example rejects. </task> <constraints> Keep the brief under 250 words besides the examples. Do not ask the vendor to find friends of the team. If last time failed on a specific trait, make that trait a hard quota. No internal jargon. </constraints> <format> Headed sections: Profile, Quotas, Screener, Incentive, Schedule, Reject list, Examples. Ready to paste into email. </format>

You are a research coordinator who writes participant-facing copy that gets people to book and show up. <context> My invite emails are long and my no-show rate is high. I need short incentive and scheduling copy for email, calendar, and a reminder that does not sound like marketing. </context> <inputs> - Incentive amount and form: [INCENTIVE] - Session length: [SESSION LENGTH IN MINUTES] - Format: [REMOTE OR IN PERSON] - Booking link: [BOOKING LINK] - Study topic in plain words: [PLAIN TOPIC] - Reminder timing: [REMINDER TIMING] </inputs> <task> Write three pieces: a 80-word invite email, a 40-word calendar description, and a 40-word reminder. Each must state time, incentive, and how to cancel. </task> <constraints> Do not hype the product. Do not hide that this is a usability test. State the incentive as a fact, not a gift. Include the cancel path in every piece. No emoji. </constraints> <format> Three labeled blocks: Invite email, Calendar description, Reminder. Subject lines on their own line above the email and reminder. </format>

You are a research operations manager who keeps a study on schedule when a participant does not arrive. <context> I lose a session almost every study to a no-show and then scramble. I need a written protocol my moderator and I can follow in the first ten minutes after the start time. </context> <inputs> - Session length: [SESSION LENGTH IN MINUTES] - Backup participants available: [BACKUP LIST STATUS] - Incentive rule on no-show: [NO SHOW INCENTIVE RULE] - Latest start I will accept: [LATE START CUTOFF] - Tool we use: [SESSION TOOL] </inputs> <task> Write a minute-by-minute protocol from T+0 to T+15 covering the ping, the late cutoff, when to release the slot, how to pull a backup, and what to log for the study record. </task> <constraints> Do not shame the missing participant in any message. Keep moderator-facing steps under 12 lines. Backup pull must not require a new screener if they already passed. State what gets paid and what does not. </constraints> <format> A timed checklist, then two short message templates: ping to the missing person, and note to the backup. End with a 3-field log line. </format>

You are a UX researcher who measures product experience in a screener without telling people the right answer. <context> I need a mix of first-timers and weekly users, but my current question asks How often do you use [product] and everyone picks weekly to get in. </context> <inputs> - Product or category: [PRODUCT CATEGORY] - Experience mix I need: [EXPERIENCE MIX] - Competitor or analog tools: [RELATED TOOLS] - Disqualify power users: [YES OR NO] - Sample size: [SAMPLE SIZE] </inputs> <task> Write a 5-question experience block that infers frequency and skill from recent behavior and tool choice, plus a scoring key that assigns Novice, Intermediate, or Expert without the participant seeing those labels. </task> <constraints> Never name the experience mix in the questions. Include at least one question about last-week behavior, not typical behavior. If power users should be excluded, do it with a behavior rule, not a self-rating. Keep questions multiple choice. </constraints> <format> Five numbered questions with options, then a scoring key that maps answer patterns to Novice, Intermediate, Expert, or Disqualify. </format>

You are a product researcher who writes one-page findings memos that executives actually finish. <context> I need a memo for people who will not watch clips or read the full report. It has to say what we learned, how sure we are, and what decision it points to. </context> <inputs> - Study goal: [STUDY GOAL] - Theme list with counts: [THEMES WITH SESSION COUNTS] - Severity-rated issues: [RATED ISSUE LIST] - Decision this study was meant to inform: [PRODUCT DECISION] - Audience: [EXECUTIVE AUDIENCE] </inputs> <task> Write a one-page memo with a 3-line headline finding, the 3 issues that matter for the decision, confidence, and a recommended next step that is a decision, not more research unless the sample is too thin. </task> <constraints> Keep the memo under 220 words. Do not bury the worst issue. Do not include methodology beyond sample size and format in one sentence. No clip timestamps. No solution sketches longer than a phrase. </constraints> <format> Labeled sections: Headline, What we saw, What it means for [PRODUCT DECISION], Confidence, Ask. No cover paragraph. </format>

You are a product manager who turns usability findings into tickets a designer and engineer can pick up without rereading the report. <context> We just finished a study and I need tickets that describe the problem, the evidence, and the acceptance check, not tickets that say Fix onboarding. </context> <inputs> - Rated findings: [RATED FINDING LIST] - Surfaces involved: [SURFACES OR SCREENS] - Ticket tool: [TICKET TOOL] - Acceptance style we use: [ACCEPTANCE STYLE] - What is already on the board: [EXISTING TICKETS] </inputs> <task> Write one ticket per finding that is worth filing. Include title, problem in user terms, evidence, severity, and an acceptance check. Skip findings that duplicate an existing ticket and say which one they match. </task> <constraints> Titles under 80 characters. Do not prescribe a visual design unless the finding is about copy. Acceptance checks must be testable in a later session or in analytics. Maximum 8 tickets. </constraints> <format> One block per ticket with Title, Problem, Evidence, Severity, Acceptance. Then a short list of findings mapped to existing tickets. </format>

You are a senior product designer who pairs each usability recommendation with a honest effort guess so the team can choose. <context> Stakeholders want recommendations, not just issues. I need options that range from a copy change to a flow change, with impact and effort so we do not only hear the biggest redesign. </context> <inputs> - Finding: [FINDING STATEMENT] - Severity: [SEVERITY SCORE] - Current flow: [CURRENT FLOW SUMMARY] - Team capacity this month: [TEAM CAPACITY] - Constraints I cannot break: [HARD CONSTRAINTS] </inputs> <task> Propose three recommendations for the same finding: a small change, a medium change, and a larger change. For each, state impact on the finding, effort, and what you would measure after ship. </task> <constraints> Honor the hard constraints. Do not offer a rewrite of the whole product. Effort must be T-shirt sizes S, M, or L with a one-line why. Keep each option under 50 words besides the measure. </constraints> <format> Three numbered options, each with Change, Impact, Effort, Measure after ship. End with one line naming the option that fits this month's capacity. </format>

You are a UX research manager who runs 25-minute readouts that end with a decision, not a highlight reel. <context> I have 25 minutes with a mixed stakeholder group and I need an outline that gets through evidence and a decision without spending half the time on method. </context> <inputs> - Study goal: [STUDY GOAL] - Top findings: [TOP FINDINGS] - Decision needed today: [DECISION NEEDED] - Attendee roles: [ATTENDEE ROLES] - Clips I can play: [CLIP LIST] - Time box: [MEETING LENGTH IN MINUTES] </inputs> <task> Build a minute-by-minute readout outline with what you say, which clip if any, and the decision question you will ask. Reserve the last 5 minutes for the decision, not extra findings. </task> <constraints> Method gets 60 seconds max. Play at most two clips. Do not add a parking lot that eats the decision time. If attendees include people new to the product, add a 30-second product reminder, not a tour. </constraints> <format> A timed agenda table: Minutes, What you show or say, Decision or not. Close with the exact decision question in quotes. </format>

You are a product researcher who compares a new usability study to an earlier one so the team can see what actually moved. <context> We ran a similar study before a redesign and I need a comparison that shows what improved, what stayed broken, and what we cannot compare because the tasks changed. </context> <inputs> - Prior study summary: [PRIOR STUDY SUMMARY] - New study findings: [NEW STUDY FINDINGS] - Tasks that stayed the same: [SHARED TASKS] - Tasks that changed: [CHANGED TASKS] - Redesign that shipped in between: [WHAT SHIPPED] </inputs> <task> Write a comparison covering shared tasks only for improvement or regression, a separate list of new issues, and a list of claims you refuse to make because the tasks changed. </task> <constraints> Do not claim a win on a task that was rewritten. If sample sizes differ, say that before any percentage. Keep the piece under 200 words. No severity inflation to make the redesign look good or bad. </constraints> <format> Three sections: Moved on shared tasks, New or remaining issues, Do not claim. Use short bullets, not paragraphs. </format>