When to use it
Before recruiting anyone. The plan is what you agree with whoever commissioned the study: what will be found out, with which method, with whom, when, and which decision depends on the result.
Its real job is not documentation, it is that everyone understands the same thing before money is spent. When a project derails, you can almost always point at the sentence in the plan that nobody read the same way.
Two to four hours for the one-page version. The formal version with budget and risks takes eight to sixteen, and most of the time it is not needed.
Before you use it
One page is the target, not the floor. One of this deliverable's quality criteria is brevity: if your plan needs ten pages to explain itself, the scope is probably unresolved. The template marks the optional sections so you delete them, not so you fill them.
Three research questions, maximum. If a fourth appears, something is out of scope or it is another project. It is the constraint that saves the most argument later.
Method comes after the problem. The most common mistake is the other way round: arriving with "we want to run interviews" and only then asking what to find out. If you wrote the method before the questions, go back.
And the stage comes before the method. Generative to understand what is going on, evaluative to find out whether something works. Evaluative research needs something concrete in front of the participant: if the prototype does not exist yet, it is not that you are short of time, it is that the method is a different one.
Logistics are not admin. In person or remote, moderated or unmoderated, lab or field: those decisions change the data you get, which is why they belong in the plan and are not improvised the week of fieldwork.
A plan that concludes "no research needed" is a good outcome. It has happened to me, and it is still the cheapest thing that can happen: finding out here costs a meeting; finding out afterwards costs the whole study.
Two sections do not leave the team. Risks and budget are marked in the document; they get deleted in the copy the client sees.
Everything in brackets gets replaced. The worked example lives on this page and not in the downloadable file.
The document
This is what you download and fill in.
Study: [study name] Lead: [name · role] Client contact: [name · role] Status: [Draft / In review / Approved] Date: [DD/MM/YYYY]
1. Problem and context
[What is going on, in two or three sentences and without jargon.]
What we already know: [what the data that already exists says] What we do not know: [the gap this study is here to fill] The decision that depends on this: [what will be decided with the result, and when] Risk of not doing it: [what gets decided anyway, on what evidence, and what being wrong costs]
If the decision line is left empty, the study has no reason to exist yet. "No research needed" is a valid outcome of this plan, and it is far cheaper to find that out here than after running the study.
2. Research questions
Three at most.
| # | Question | Method | Deliverable |
|---|---|---|---|
| Q1 | [ … ?] | [method] | [what it produces] |
| Q2 | [ … ?] | [method] | [what it produces] |
| Q3 | [ … ?] | [method] | [what it produces] |
Out of scope: [what this study will not answer, said now]
3. Method
Stage: [generative, to understand what is happening · evaluative, to find out whether something works] · [formative, before launch · summative, to measure what shipped]
This is decided before the method, because it determines it. Evaluative research needs something concrete in front of the participant; if that does not exist yet, the method is a different one.
What you put in front of them: [nothing · low-fidelity prototype · high-fidelity prototype · product in production] — only if the stage is evaluative.
Fidelity decides what you can conclude: at low fidelity you test the flow and comprehension, not the interface or time on task.
[What will be done: how many sessions, how long, with which instruments.]
Why this method and not another: [one sentence; it is the one you will be asked for later]
Logistics: [lab · field] · [in person · remote] · [moderated · unmoderated] · Tool: [which one]
This is not an administrative detail: context changes the data. Remote is more accessible and loses nuance; unmoderated scales and leaves no room to ask why.
Instruments: [interview guide / screener / informed consent / usability test protocol] — [links]
4. Participants
| Criterion | Definition | Quota |
|---|---|---|
| [inclusion criterion] | [behavioural definition, not demographic] | [n] |
| [contrast criterion] | [definition] | [n] |
| [exclusion] | [who does not qualify and why] | — |
Recruitment: [where they come from] · Incentive: [amount] · Over-recruit [20%].
5. Timeline
| Stage | Dates | Owner | Needed from the client |
|---|---|---|---|
| Design and instruments | [week] | [who] | [what you need from them] |
| Recruitment | [week] | [who] | |
| Fieldwork | [week] | [who] | |
| Analysis | [week] | [who] | |
| Delivery | [week] | [who] |
The last column is what prevents the "the study slipped" conversation.
6. Deliverables
- [What they receive, in what format]
- [What they receive]
- [Handover workshop of (X) min, if it applies]
7. Method note and limitations
[What this study will be able to say and what it will not. If it is qualitative: it describes reasons and mechanisms, not proportions.]
[Internal only · delete from the client's copy]
8. Assumptions and risks
| Risk | Likelihood | Mitigation |
|---|---|---|
| [risk] | [high/medium/low] | [what you do if it happens] |
9. Budget and hours
| Item | Hours | Amount |
|---|---|---|
| Design and instruments | [ ] | [ ] |
| Fieldwork | [ ] | [ ] |
| Incentives | — | [ ] |
| Analysis and delivery | [ ] | [ ] |
| Total |
The worked version
The same document with a case written end to end: an invented study on the sign-up flow of a personal finance app. It shows what level of detail each field expects before you face the empty version. It downloads separately.
Internal version. It includes the team's assumptions, risks and budget. The version shared with the client omits sections 8 and 9.
1. Project details
| Field | Value |
|---|---|
| Client | [Client name] |
| Project | [Onboarding for a personal finance app] |
| Lead | [Name · role] |
| Client contact | [Name · role] |
| Field window | [DD/MM/YYYY – DD/MM/YYYY] |
| Status | [Draft · In review · Approved] |
| Template version | v1.0 · last reviewed [DD/MM/YYYY] · see the original at UXR |
2. Problem and context
The app has high drop-off during sign-up. The team knows people leave, but not at which step or why. Product data shows the aggregate drop; it does not explain the decision to close the app.
What we already know: [overall drop-off rate], [step with the largest drop according to analytics], [related support tickets].
What we do not know: what information the user is missing at each step, what creates distrust, and whether the drop-off is final or postponed.
The decision that depends on this: [redesign the bank-linking step vs. reorder the sign-up sequence], with a decision date of [DD/MM].
3. Research questions
| # | Question | Method | Deliverable |
|---|---|---|---|
| Q1 | Which step do they stop at, and what are they thinking there? | Interviews with a guided walkthrough | Findings and severity matrix |
| Q2 | What information does the app ask for that the person does not have at hand? | Interviews + heuristic review | Heuristic report |
| Q3 | How widespread is distrust about linking a bank account? | Survey of the installed base | Survey report |
Three questions at most. If a fourth appears, something is out of scope or it is a different project.
4. Method
4.1 Stage, and what goes in front of the participant
Evaluative and formative: sign-up already exists and we want to know why it fails before redesigning it, not to measure how much it improved afterwards.
What goes in front of them: the sign-up flow in production, on the participant's own phone. No prototype: the problem is in what is already shipped.
4.2 Design
Qualitative first, quantitative after. [10] semi-structured interviews of [60] min with a guided walkthrough on the participant's device, remote over video call with screen sharing. Then a [8]-question survey to [n] users of the installed base, to size the patterns found.
4.3 Why this method and not another
A classic usability test would measure whether the task is completed; we already know it is not. What is missing is the reason, and that shows up in conversation during the walkthrough. The survey alone is no use yet: we do not know what to ask.
4.4 Logistics
Remote, moderated, over video call with screen sharing. Remote because the segment is spread across several cities; moderated because the question is why, and that gets asked in the moment.
4.5 Instruments
- Recruitment screener — [link]
- Interview guide (internal and participant versions) — [link]
- Findings and severity matrix — [link]
- Informed consent — [link]
5. Sample and recruitment
| Criterion | Definition | Quota |
|---|---|---|
| Abandoned sign-up | Downloaded and did not complete activation, last 60 days | 6 |
| Completed sign-up | Activated the account, last 60 days (contrast group) | 4 |
| Variable income | Self-employed, freelance or invoicing per job | min. 4 |
| Exclusion | Works in banking, fintech, design or research | — |
Recruitment: [own panel / client's base / agency]. Incentive [amount] per session. Over-recruit [20%] for no-shows.
6. Timeline
| Stage | Dates | Owner | Needed from the client |
|---|---|---|---|
| Design and instruments | [week 1] | [UXR] | Plan approval |
| Recruitment | [weeks 1–2] | [UXR] | Access to the user base |
| Fieldwork | [week 3] | [UXR] | A stable test environment |
| Analysis | [week 4] | [UXR] | — |
| Delivery and workshop | [week 5] | [UXR + client] | Product team attendance |
7. Deliverables
- Insights presentation ([n] slides) with prioritized recommendations.
- Findings and severity matrix, with estimated effort.
- Customer journey map of the activation process.
- [90] min handover workshop with the product team.
8. Assumptions and risks
Internal only
| Risk | Likelihood | Mitigation |
|---|---|---|
| We cannot reach the people who abandoned sign-up | High | External recruitment with our own screener |
| The test environment goes down during the walkthrough | Medium | Backup Figma prototype with the same steps |
| The team expects drop-off figures from the qualitative part | High | An explicit method note in the delivery and in the workshop |
9. Budget and hours
Internal only
| Item | Hours | Amount |
|---|---|---|
| Design and instruments | [ ] | [ ] |
| Fieldwork ([10] sessions) | [ ] | [ ] |
| Incentives | — | [ ] |
| Analysis and delivery | [ ] | [ ] |
| Total | [ ] | [ ] |
10. Method note and limitations
With [10] interviews the findings describe reasons and mechanisms, not proportions of the population. The follow-up survey sizes them; the qualitative part explains them. No number from the qualitative phase is presented as a percentage. The group that completed sign-up is included as a contrast, not as a representative sample of active users.
UXR SpA · User research [contacto@uxr.cl] · [uxr.cl]
Template v1.0 · reviewed [DD/MM/YYYY] Original at UXR — check that your copy has not expired
The one-page version
If the project is small or the team already knows each other, the full plan is overkill. The short version keeps four things and deletes the rest:
- The problem and the decision that depends on the study.
- The research questions.
- The method in two lines.
- Who takes part and when.
That fits on a page and does the work that matters: nobody discovers halfway through that they understood something different.
A worked example
A study on the onboarding of a personal finance app.
Problem: high drop-off during signup. The team knows people leave, but not at which step or why; product data shows the aggregate drop and does not explain the decision to close the app.
Decision that depends on it: redesign the bank-linking step, or reorder the signup sequence.
Questions: which step they stop at and what they are thinking there; what information the app asks for that people do not have to hand; how widespread the distrust of bank linking is.
Method: ten interviews with a guided walkthrough, then a survey to the installed base to size it. Qualitative first because we do not yet know what to ask in the survey.
That last criterion — qualitative to understand, quantitative to size — is what makes the "why this method and not another" section write itself.
This example lives here only, not in the downloadable file.
Check before using it
- Is the "decision that depends on this" line filled in?
- Are there more than three research questions?
- Did you write the method before the questions?
- Does the "out of scope" section say something concrete?
- Is the "requires from the client" column of the timeline complete?
- Did you delete sections 8 and 9 in the copy that goes to the client?
- Any bracket left unreplaced?
Grounding
The required components and the quality criteria come from this site's Research Plan entry, where they appear in more detail.
The formative/summative distinction (Tullis and Albert, 2008, pp. 45-46), the generative/evaluative one and the logistics decisions in section 3 are worked through in How to choose a UX Research methodology, where I go through the six criteria and the order I use them in.
The instruments the plan lists have their own templates: the interview guide, the screener, the informed consent and, if the stage is evaluative, the usability test protocol.