The UX research prompts below cover the full study cycle: planning, recruiting, writing test scripts and surveys, reviewing designs, and turning raw session notes into findings people act on. Each one asks for a specific output and keeps the model honest about what is evidence and what is a guess.
How to use these prompts
Every prompt is ready to copy into ChatGPT, Claude or Gemini. Replace the blanks in double braces, or keep the default after the colon: {{product:a meal kit subscription app}} means "a meal kit subscription app" unless you change it.
Three habits matter more than the wording. First, paste the real material: the research question, the session notes, the survey export, the screenshots. Second, keep each prompt to one job. OpenAI's ChatGPT prompting guide says it directly: "Tight scope usually beats a 'do everything' prompt." Third, never let the model stand in for participants. It can draft, organize and critique, but it has not watched anyone use your product.
Before you paste anything from sessions, remove names and identifying details, and check that your consent form covers the tools you use. For interview guides, interview synthesis and feedback tagging, see the product manager prompts; this page covers the rest of the research job.
Which prompts help plan a study?
1. Turn a question into a research plan
Use it when someone asks "can we do some research on this?" and you need to pick a method before anything else.
I need a research plan for {{product:a meal kit subscription app}}.
The decision this research should inform: {{decision}}
What we already know: {{known}}
Constraints: {{constraints:3 weeks, no budget for incentives over $50}}
Give me:
1. Two or three research questions, phrased so a study can answer them.
2. The method you recommend (usability test, interviews, survey, diary
study, analytics review, or a mix) and why it fits the decision.
3. One method you considered and rejected, and why.
4. Who to recruit, how many, and the main screening criteria.
5. A week-by-week timeline.
6. What this plan cannot tell us.
2. Write a participant screener
A screener decides who you learn from. The instruction about hiding the "right" answer keeps people from guessing their way in.
Write a screener survey to recruit {{count:6}} participants for
{{study:a usability test of our checkout flow}}.
Who we want: {{target}}
Who we must exclude: {{exclude:employees, people in UX or market research}}
Rules:
- 8 to 12 questions, mostly multiple choice.
- Don't reveal which answers qualify. Mix the qualifying option in with
plausible alternatives.
- Ask about past behavior ("In the last month, how often...") rather than
opinions or intentions.
- Include one open-ended question that shows how well a person explains
things.
After the questions, give the qualify and disqualify logic for each one.
3. Usability test script with task scenarios
Good tasks give a goal and a reason, not instructions. This prompt asks for both the script and the success criteria you will score against.
Write a moderated usability test script for {{product:a meal kit subscription app}}.
Session length: {{length:45 minutes}}. Format: {{format:remote, think-aloud}}.
Flows to test: {{flows}}
Include:
- An intro the moderator reads, covering consent, recording and "we're
testing the design, not you".
- 2 or 3 warm-up questions about the participant's current habits.
- 4 to 6 task scenarios. Each one gives a realistic goal and context, never
the names of buttons or menu items. Add what counts as success for each
task and what the moderator should watch for.
- Neutral follow-up prompts for when a participant goes quiet or asks for
help.
- Closing questions and a wrap-up.
4. Check survey questions for bias
Run your draft survey through this before it goes out. Leading, double-barreled and loaded questions are easy to write and hard to spot in your own work.
Review this survey draft. For each question, check for:
- Leading or loaded wording
- Two questions in one (double-barreled)
- Answer options that overlap or leave people out
- Jargon the audience may not know
- Questions about the future or hypotheticals where past behavior would
be more reliable
Give a table: question number, problem, why it matters, rewritten question.
Then suggest the order the questions should go in, and flag any question we
could cut without losing something we need for {{goal}}.
Survey:
{{survey}}
Which prompts help run sessions?
5. Dry-run the script before the pilot
A model can't be a real participant, but it can play one well enough to expose confusing tasks and gaps in your script before you spend a real session on them.
Act as a first-time user of {{product:a meal kit subscription app}} taking
part in a usability test. Your profile: {{profile}}.
I'll read my test script one step at a time. Respond the way a real
participant might, including misreading a task when its wording allows it.
After each task, step out of character and tell me in one line if the task
wording was ambiguous, gave away the answer, or assumed knowledge.
This is a script rehearsal only. Nothing you say counts as research data.
6. Observer note-taking sheet
Observers take better notes when they know what to watch for. Share this sheet with everyone who joins a session.
Make a note-taking sheet for observers of this usability test. One section
per task with: the task goal, the success criteria, columns for "what they
did", "what they said (quote)", "where they hesitated or erred", and
"severity guess". Add a short guide at the top on writing observations
(what happened) separately from interpretations (why you think it happened).
Test script:
{{script}}
Which prompts help analyze what you saw?
7. Session notes to usability issues
Paste one session at a time. Asking for quotes before conclusions keeps the issues tied to what actually happened.
Here are notes from one usability session of {{product:a meal kit subscription app}},
participant {{participant_id:P1}}.
1. List every usability issue the notes support. For each, quote or
paraphrase the evidence from the notes.
2. Rate each issue: critical (blocked the task), serious (caused real
delay or errors), minor (noticeable friction).
3. Note which task it happened in.
4. If the notes are too thin to judge something, say so instead of
guessing.
Notes:
{{notes}}
8. Count issues across participants
After the per-session pass, combine them. A table of who hit which issue shows patterns and stops one vivid session from dominating.
Below are the usability issues from {{count:5}} sessions, each labeled with a
participant ID. Merge issues that describe the same underlying problem, then
make a table with one row per merged issue and one column per participant,
marking who hit it. Add columns for severity and the task.
Sort by how many participants hit it, then by severity. Under the table, list
issues that only one person hit but that were critical, since frequency
alone would hide them.
Issues:
{{issues}}
9. Analyze open-ended survey answers
For the free-text column in a survey export. The codebook step makes the result repeatable and checkable.
Below are {{count:200}} open-ended answers to the survey question
"{{question}}".
1. Read them all, then propose a codebook of 6 to 10 codes. Each code gets a
name, a one-line definition, and an example answer.
2. Apply the codes to every answer (an answer can have more than one).
3. Give a table of codes with counts and percentages.
4. For the top three codes, quote three representative answers each.
5. List answers you could not code with confidence.
Answers:
{{answers}}
Which prompts help with expert reviews?
10. Heuristic evaluation first pass
Jakob Nielsen's 10 usability heuristics are a standard checklist for expert review. Attach screenshots if your model accepts images, or describe the flow step by step.
Review this {{surface:sign-up flow}} against Jakob Nielsen's 10 usability
heuristics (visibility of system status, match between the system and the
real world, user control and freedom, consistency and standards, error
prevention, recognition rather than recall, flexibility and efficiency of
use, aesthetic and minimalist design, helping users recognize, diagnose and
recover from errors, and help and documentation).
For each problem you find: the screen or step, the heuristic it breaks, what
a user might experience, a severity guess, and a suggested fix. Only report
problems you can see in what I provided. List anything you would need to
see in a working prototype to judge.
{{screens_or_description}}
11. Accessibility first pass
Useful for catching obvious problems early. It is not an audit: test with assistive technology and check against WCAG 2.2, the version W3C currently encourages teams to use.
Do a first-pass accessibility review of this {{surface:checkout page}} for
people using screen readers, keyboard only, magnification, or with low
vision or color blindness.
Look at: text alternatives, color contrast, focus order and visibility,
form labels and error messages, touch target size, and anything that relies
on color, motion or timing alone. For each issue, say who it affects and
how to fix it. Mark which issues need testing with real assistive
technology to confirm.
{{screens_or_markup}}
12. Journey map from research
Build the map from evidence you already have, not from a workshop's assumptions.
Using only the research evidence below, draft a journey map for
{{persona:a first-time customer}} trying to {{goal:place their first order}}.
Stages as columns. For each stage: what they do, what they think or feel
(with a supporting quote), pain points, and opportunities. Mark any cell
where the evidence is thin with "Needs research". Don't fill gaps with
assumptions.
Evidence:
{{evidence}}
Which prompts help share findings?
13. Findings readout people read
Most research reports are too long. This one leads with what to do.
Write a research readout for {{audience:the product team and our VP}}
from the findings below.
Structure:
1. Three to five key findings, each in one sentence with the evidence count
(for example "4 of 5 participants...").
2. What we recommend, tied to each finding.
3. What surprised us.
4. What we still don't know and how we could find out.
5. Method in two sentences: who, how many, when.
Keep it under {{length:600 words}}. Use the participants' own words for one
quote per finding. Don't overstate: five participants show a problem exists,
not how common it is.
Findings:
{{findings}}
14. Turn findings into design questions
Bridges the gap between "here is what we saw" and the design work that follows.
For each research finding below, write:
- A "How might we" question that opens up solutions without picking one.
- Two different directions a designer could explore.
- How we would know a solution worked (what to measure or test next).
Keep the original finding next to each one so nobody loses the evidence.
Findings:
{{findings}}
How many participants do these prompts assume?
The analysis prompts default to small qualitative rounds. Nielsen Norman Group's article on testing with 5 users argues that "The best results come from testing no more than 5 users and running as many small tests as you can afford." The same article adds caveats: test at least 3 users per group when you have distinct groups, and its follow-up guidance calls for 20 users in quantitative studies. Adjust the {{count}} blanks to match your study, and when you write a readout, report counts ("4 of 5") rather than percentages from a handful of people.
How do you keep the model honest about evidence?
Ask for evidence before conclusions, and give the model a way out when the notes don't support a claim. Anthropic's guide to reducing hallucinations recommends both: explicitly allow the model to say it doesn't know, and on long documents, ask it to extract word-for-word quotes before doing the task. Prompts 7, 9 and 12 build that in. Spot-check a few quotes against your notes before a finding goes into a readout.
Keep your research prompts in one place
If you run the same session analysis after every test, turn it into a skill with the SKILL.md generator, so Claude Code or Codex follows it the same way each time. For design-side work after the research, see the UI UX Pro Max skill.
Kipt stores prompts like these as Markdown files in a private GitHub repo you own. The blanks stay fillable, so {{product}} and {{count}} change per study, and ⌘K finds the screener or the readout prompt when you need it.