User Research Plan Template: How to Plan Research That Gets Used

A user research plan is a short document — typically one to two pages — that aligns your team on what you're studying, why, how, and by when. It's one of the most underrated tools in a researcher's toolkit: simple to write, but invaluable for preventing scope creep and securing stakeholder buy-in before you've spent a week in the field.

Why You Need a Research Plan

Research without a plan tends to meander. Scope expands mid-study. Stakeholders ask "but did you ask them about X?" after the fact. Findings arrive too late to influence the decision they were supposed to inform.

A research plan prevents all of that. It forces clarity before you start, surfaces misalignments early when they're cheap to fix, and creates a shared artifact everyone can reference throughout the project.

According to the Nielsen Norman Group, the most common reason research fails to influence product decisions is poor communication about objectives and scope — exactly what a research plan is designed to solve.

The User Research Plan Template

Here's a complete template you can adapt for any study.

---

Research Plan: [Project Name]

Date: [Date created] Researcher(s): [Name(s)] Stakeholders: [Names and roles] Decision this research will inform: [One sentence — what decision hangs on this study?]

---

Research Question

[One to two sentences. What do you want to learn? The more specific, the better.]

Example: Why do power users build custom dashboard views rather than using our built-in templates, and what would need to change for them to switch?

Background and Context

[2–3 sentences. Why are you doing this now? What triggered the study? What do you already know?]

Hypotheses

[List 2–3 assumptions you believe to be true that you want to test or explore through this research.]

Methodology

[Which method(s) will you use? Include a brief rationale for why this approach fits the research question.]

Participants

• Number: [e.g., 8 interviews]
• Criteria: [Specific qualifying criteria — role, company size, recency of behavior]
• Exclusions: [Who to screen out — competitors, existing beta users, etc.]
• Recruitment approach: [How you'll find and reach participants]

Timeline

Deliverables

[What will you produce, and for whom? e.g., written findings summary for product team, presentation to leadership, tagged insights in research repository]

---

How to Fill In Each Section

Research Question

The research question is the most important part of your plan. Get this wrong and everything downstream is misaligned.

A good research question:

• Focuses on user behavior, motivation, or experience — not "what should we build"
• Is specific enough to be answerable in the time you have
• Is tied to a real product or business decision

Weak: "Understand how customers use our analytics features."

Strong: "Why do power users build custom dashboards rather than using built-in views, and what would need to change for them to switch?"

The strong version tells you exactly who to talk to, what to explore, and what a useful answer looks like.

The "so that" test: Fill in this sentence: "We want to understand [research question] so that [specific product decision]." If you can't complete the second half, the research may not be actionable.

Background and Context

Keep this brief — two or three sentences explaining what triggered the study and what you already know. This helps stakeholders calibrate the research against existing knowledge and avoids duplicating previous findings.

If there's relevant prior research (a survey, previous interviews, analytics data), reference it here.

Hypotheses

Writing hypotheses before you conduct research is a discipline, not a prediction. It forces you to be explicit about your current beliefs so you can test them — and notice when the data contradicts them.

Good hypotheses are falsifiable: "We believe users abandon setup because they don't understand the value of the customization step." A good interview can either support or contradict this.

Avoid vague hypotheses like "users find this confusing." That's not testable — everything is confusing to someone.

Methodology

Choose your method based on the research question, not habit or convenience.

Include a one-sentence rationale: "We're using semi-structured interviews because we need to understand motivation and context, which a survey can't capture."

Participants

This section is where most plans are too vague. "Product managers at tech companies" is a segment, not a screener. Specify:

• Role and seniority (not just job title)
• Company size or stage (a solo founder's research practice looks very different from a researcher at a Fortune 500)
• Recency of the behavior you're studying (only talk to people who have experienced the problem recently)
• Exclusions (competitors, internal staff, people who already know your product too well)

A tight screener makes your findings more reliable and your analysis faster.

Timeline

Build in more time than you think you need for two phases in particular: recruitment (participants are hard to pin down) and analysis (insights don't synthesize themselves).

A realistic timeline for a 6–8 interview study:

• Week 1: Finalize plan, write discussion guide, begin recruitment
• Week 2: Conduct interviews (2–3 per day maximum to prevent fatigue)
• Week 3: Analysis and synthesis
• Week 4: Write findings and present

How AI platforms compress this: With Koji, you can collect all 8 interview responses within 24–48 hours of launching your study (assuming participants are ready), moving directly to analysis while data is still fresh.

Deliverables

Be explicit about what you're producing and who it's for. Different stakeholders need different formats:

• Product team: A 2-page findings summary with direct quotes and recommendations
• Design team: Annotated user journey map or session clips with findings in context
• Leadership: A one-paragraph executive summary with 3 key insights and their implications

Specifying deliverables upfront prevents the "so what are you going to give us?" question at the end.

Adapting the Template for Different Study Types

For discovery research: Emphasize the "background and context" and "hypotheses" sections. The goal is to explore openly, so your research question may be broader and more open-ended.

For evaluative research (usability, concept testing): Add a "success criteria" section. What does good look like? What would cause you to recommend changes?

For continuous discovery: Simplify the plan into a lightweight weekly template: research question this week, participant criteria, key themes to explore, output format.

Using Koji to Execute Your Research Plan

Once your research plan is written, Koji can accelerate the execution phase significantly:

1. Describe your research question and participant criteria to the AI consultant, which generates a tailored interview brief.
2. Review and edit the brief — adjust the interview structure, question framing, and tone for your specific audience.
3. Publish your study and share the interview link with your recruited participants.
4. Monitor responses in real-time — Koji analyzes each interview as it's completed.
5. Review the aggregate report when data collection closes — themes, sentiment, and illustrative quotes are automatically synthesized.

This workflow compresses the "plan to insights" timeline from weeks to days, making it practical to run research studies as frequently as your team needs them.

Research Plan Mistakes to Avoid

Writing the plan after you've already designed the study. A research plan written after the fact is documentation, not planning. Write the plan first — before you design your discussion guide or start recruiting.

Skipping the stakeholder review. The plan only works if the people whose decisions depend on your research have seen and agreed to the research question. A 15-minute review call before fieldwork begins is worth far more than a 60-minute debrief afterward.

Leaving deliverables vague. "Share findings with the team" is not a deliverable. Specify format, length, audience, and date.

Over-specifying the discussion guide in the plan. The plan should describe your approach, not script your interview. Include 3–5 topic areas at most — save the detailed questions for the discussion guide itself.

Key Takeaways

• A research plan is a one-to-two page document that aligns your team before fieldwork begins.
• The research question is the most important element — make it specific, actionable, and tied to a real decision.
• Write tight participant criteria: "product managers at tech companies" is a segment, not a screener.
• Specify deliverables and stakeholders upfront so findings land in the right hands in the right format.
• AI interview platforms like Koji can compress your fieldwork timeline from weeks to days by running asynchronous, AI-moderated interviews at scale.

Frequently Asked Questions

Q: How long should a research plan be? A: One to two pages. If your plan is longer, you're likely including information that belongs in the discussion guide or deliverables document. Keep it scannable — stakeholders should be able to review it in five minutes.

Q: Do I need a research plan for a small study? A: Yes, even for a 3-interview exploratory study. A half-page plan ensures you and your stakeholders are aligned on the question, participants, and output before you invest any time in fieldwork.

Q: Who should review and approve the research plan? A: Share with the product manager or team lead whose decision the research is informing. Get explicit agreement on the research question — that's where misalignments most often occur.

Q: How do I handle changes to the plan mid-study? A: Update the plan and re-share it with stakeholders. If the change is significant — different participants, different research question — consider whether data already collected is still valid.

Q: Can AI tools help me create a research plan? A: Yes. Koji's AI consultant walks you through defining your research question, choosing a methodology, and structuring your interview guide — effectively building the core of your research plan as part of the study setup process.