A UX research plan turns a broad question into a decision, a small set of observable questions, a fitting method, and evidence the team can use. Start with the decision you need to make, then record the audience, recruitment constraints, tasks, risks, and analysis plan before scheduling sessions. This template gives you a practical one-page structure you can copy into a project.
When the plan includes a journey or a proposed flow, a Mockitt prototype gives participants something concrete to react to while you keep the research question separate from a polished visual solution. A prototype is evidence for a conversation, not proof that a production interface will work.
What a UX research plan must answer
A useful plan lets a teammate answer five questions without a meeting:
- What decision is pending? Name the product or design decision and when it must be made.
- Who has relevant experience? Describe the people, context, and recent behavior that matter.
- What will we observe? Write tasks or prompts that reveal behavior instead of asking for approval.
- How will evidence change the decision? Define the signals that would support, challenge, or qualify an option.
- What is out of scope? Explicitly exclude questions that the method cannot answer.
These answers keep a study from becoming a general “user feedback” exercise. They also make a smaller, faster study defensible when the team has limited time.
A copyable UX research plan template
Fill in the fields below in plain language. A short sentence is better than a vague paragraph.
| Field | What to write | Example |
|---|---|---|
| Decision owner | The person accountable for the next decision. | Product manager for mobile checkout. |
| Decision | The choice the evidence will inform. | Choose one of two address-entry flows. |
| Research objective | The behavior or understanding you need to learn. | Learn where shoppers hesitate or recover. |
| Participants | Experience, context, and important exclusions. | Recent online shoppers who have used delivery addresses. |
| Method | Session format and why it fits the question. | Moderated task walkthrough with a clickable concept. |
| Evidence | Observable signals and how notes will be compared. | Unprompted errors, workarounds, and stated confidence after each task. |
| Risks | Bias, access, privacy, or timing risks. | Recruiting only existing customers may hide first-time confusion. |
| Decision rule | How evidence will change the next step. | Revise any step where most participants need a moderator hint. |
Choose the method from the question
Do not choose interviews because they are familiar. Match the method to the uncertainty:
- Understand context: use interviews or observation when you need to learn goals, workarounds, language, and constraints.
- Compare a proposed flow: use task-based usability sessions when you need to see whether people can complete a defined task.
- Explore a broad need: use a survey only when you can define the population, response options, and interpretation limits.
- Prioritize themes: use a structured synthesis workshop after collection; do not treat a vote as proof of prevalence.
A method can answer one kind of question well and another poorly. A participant saying “I like this” does not demonstrate that the flow is understandable, and a five-person study does not estimate the percentage of a market.
Write questions that produce evidence
Replace requests for opinions with prompts about a recent behavior. “Would you use this?” predicts little. “Tell me about the last time you changed a delivery address” reveals a sequence, vocabulary, and constraints.
For a prototype session, write a neutral task: “You need to send this order to a new address. Show me what you would do.” Avoid explaining the intended path. Record where the participant looks, what they select, what they expect next, and where they recover. Keep follow-up questions open until the task ends.
Include a stopping rule. If a participant cannot proceed, ask what they expected to happen and what they would try next. Do not quietly guide them and then record a successful completion.
Recruitment, consent, and privacy
Define an inclusion rule that can be screened consistently. “People who buy online” is broad; “people who placed a delivery order in the last three months and changed its address” is testable. Keep recruitment questions separate from the study questions so screening does not teach the expected answer.
Tell participants what will happen, what will be recorded, how long it will take, and how their information will be used. Collect only what the study needs. Remove names from notes and store recordings and contact details with appropriate access controls. If the study involves children, employees, health information, or other sensitive contexts, use the relevant review and consent process before recruiting.
Plan analysis before sessions
Create a note structure that mirrors the objective: task step, observed behavior, participant language, interpretation, and open question; plan an empathy map when a user-group summary will help. Separate what happened from what you think it means. After each session, capture a short evidence memo while details are fresh; do not wait until every memory has blended together.
At synthesis, compare observations across participants and preserve disagreement. Count occurrences only when the observation rule is consistent, and label small samples as directional. Link each theme to source notes so a product decision can be revisited later. A theme should describe a pattern and its consequence, not a solution disguised as a finding.
Turn findings into a decision
End the plan with the next action: ship a limited experiment, revise the flow, run another study, or stop the idea. Name the owner and the date for reviewing the evidence. If no result would change the decision, the study is not ready to run.
Keep the plan beside the research notes and the prototype version used in sessions. That chain makes it possible to explain which question was asked, which evidence was collected, and why the team changed the design.
Run a small pilot first
A pilot is a rehearsal, not a source of final findings. Ask one person who fits the recruitment rule to complete the tasks while you check timing, wording, recording, and prototype behavior. Note where the moderator accidentally teaches the answer, where a task depends on missing data, or where the session is longer than the participant can reasonably sustain.
After the pilot, change the script and record the change in the plan. If the change alters the research question or the evidence rule, treat the pilot as a separate phase when you analyze the results. This simple boundary prevents an early wording mistake from being mixed silently into later sessions.
Make the plan easy to review
Share a short version with the decision owner: decision, participants, method, dates, risks, and the rule for acting on evidence. Keep detailed prompts and consent language in linked working documents. Reviewers should be able to challenge the scope without editing the moderator script.
Before recruitment starts, ask one final question: “What would we do differently if the evidence contradicts our current assumption?” A specific answer creates a useful study. If the answer is “nothing,” narrow the objective or postpone the work until a decision is genuinely open.
Keep a versioned evidence trail
Give the plan a short version name and date, and record any change to the objective, participant rule, task script, or analysis rule. Link the version used in each session to the notes from that session. This does not require heavy process: a shared changelog with the reason for each change is enough for a small study.
When the decision is made, archive the final plan with the evidence memo and decision log. Future researchers can then see what was tested and where the conclusion was bounded, instead of treating an old recommendation as a timeless fact.