A UX research plan is a one-page agreement about what a study is for, who it will talk to, how, and what happens to the findings. Its job is not to be thorough; it is to be read. The plans that get ignored are the ten-page ones. The plans that change what a team builds fit on a screen and are written before the first participant is recruited.
This guide gives you the eight sections a research plan needs, a template you can copy, and a worked example.

Why write a research plan at all
Three reasons, in order of how often they bite:
- It forces the question. Most bad studies aren't badly run; they were never clearly about anything. Writing "the decision this informs" in one sentence is the whole value of the exercise.
- It gets stakeholders in before, not after. A PM who agreed to the research questions can't dismiss the answers. A PM who first sees the study at the readout can.
- It makes the study repeatable. Continuous research means running the same shape of study every month; the plan is the shape.
The eight sections of a UX research plan
1. Background and the decision
Two or three sentences: what's happening in the product, and what decision this research will inform. If you can't name a decision, stop and find one — research that informs nothing is a hobby.
2. Research questions
Three to five questions the study must answer, written as questions about users, not about the product. "Why do trial users stall at import?" is a research question. "Should we redesign import?" is the decision it informs. "Do users like the new import?" is neither.
3. Method
Which UX research method and why it fits the questions. Generative questions (why, how, what do people do today) want interviews, contextual inquiry, or diary studies. Evaluative questions (can people do this, where do they fail) want usability tests. Say what you're not doing and why, in one line.
4. Participants
Who, how many, and how you'll find them. Be specific about the segment: "ops leads at companies with 50–200 staff who ran a report in the last week", not "users". For interviews, five to eight per segment; for usability tests, five per round.
5. Timeline
Recruit, sessions, synthesis, readout — with dates. Synthesis takes as long as the sessions did; plans that allot a day for it are the ones that end with a folder of unread recordings.
6. Discussion guide or task list
Link it rather than embedding it. For interviews, a semi-structured guide of 6–12 open questions; for usability tests, the tasks and success criteria. Our interview question templates are a starting point.
7. Analysis and deliverables
How findings will be produced (thematic analysis, task-success metrics) and what form they'll take. Name the deliverable precisely — "six evidenced themes with quotes, ranked, in the research repository, plus a 20-minute readout" — so the team knows what to expect and when it's done.
8. Roles
Who moderates, who takes notes, who owns synthesis, who's in the readout. One name each.

UX research plan template
Copy this and fill it in. It should stay under a page.
Study: [name] Owner: [name] · Date: [ ]
Background & decision. [What's happening, and the decision this informs.]
Research questions.
- [ ]
- [ ]
- [ ]
Method. [Method and why. What we are not doing.]
Participants. [Segment, criteria, number, recruiting source, incentive.]
Timeline. Recruit [dates] · Sessions [dates] · Synthesis [dates] · Readout [date]
Guide. [Link]
Analysis & deliverables. [Method; exact deliverable; where it will live.]
Roles. Moderator [ ] · Notes [ ] · Synthesis [ ] · Readout [ ]

Example: a filled-in research plan
Study: Why trials stall at import Owner: Jess · Date: 2026-09-02
Background & decision. 40% of trials never complete their first import; the ones that do convert at 3× the rate. We need to decide whether to redesign the import flow or invest in onboarding help before Q4 planning.
Research questions.
- What are people trying to import, and from where?
- Where in the flow do they stop, and what do they believe is happening at that point?
- What do the ones who succeed do differently?
Method. Moderated remote sessions, 45 minutes: 20-minute semi-structured interview about their data and past attempts, then a 25-minute usability test of the import flow on their own file. Not doing a survey — we need to watch, not ask.
Participants. 8 trial users who signed up in the last 14 days: 5 who stalled at import, 3 who completed it. Recruited from the trial list by email with a $75 incentive.
Timeline. Recruit Sep 3–6 · Sessions Sep 9–12 · Synthesis Sep 15–16 · Readout Sep 17
Guide. [link to guide]
Analysis & deliverables. Thematic analysis of interview portions; task-completion and failure points for the test portion. Deliverable: ranked themes with quotes and clips in the repository, one-page summary, 20-minute readout to product and design.
Roles. Moderator Jess · Notes Sam · Synthesis Jess · Readout Jess + Sam
Mistakes that make plans get ignored
- No decision named. The most common one. If the plan doesn't say what changes based on the answer, nobody will act on the answer.
- Product questions instead of research questions. "Do users want dark mode?" is a question the study cannot answer honestly.
- "Users" as the participant spec. Recruiting without a segment produces themes that apply to no one in particular.
- Synthesis not scheduled. The sessions happen; the analysis doesn't. Budget the time, or use tools that do the first pass for you — Intervool transcribes each session and pulls out the pain points and quotes as they land, so synthesis starts the day the sessions do rather than the week after.
- The plan as a document nobody can find. Put it where the findings will go — in the research repository, next to the sessions it produced.




