UX Research Plan Template: How to Structure Any Research Project

A UX research plan is a one-page document that aligns your team on what you are studying, why it matters now, how you will conduct the research, and what you will do with the findings. It prevents wasted effort, stakeholder confusion, and research that produces data no one acts on.

Before any research begins, a research plan answers seven questions: What are we trying to learn? Why does it matter? Who will we study? How will we conduct the research? When will it happen? How many participants do we need? And what happens after?

Think of a research plan as a project brief for research. Writing it forces clarity that benefits every stage of the process. Getting stakeholder sign-off on it before fieldwork begins prevents the dreaded "but we wanted to know about X" conversation after the fact.

Why Research Plans Get Skipped — and Why That Is a Mistake

Most teams skip research plans because they feel like overhead. "We know what we want to learn — let's just do the interviews." This is exactly when research produces data that surprises no one, informs nothing, and gets filed away.

According to Nielsen Norman Group, 42% of product decisions made without documented research rationale are later found to have been wrong when tested. Research plans are not bureaucracy — they are the mechanism that connects research investment to decision-making.

A well-written research plan takes 30–60 minutes to produce. It saves multiples of that time downstream through clearer recruitment, sharper interviews, and findings that map directly to open decisions.

The 7-Part UX Research Plan Template

1. Research Question(s)

Write 1–3 specific questions your research will answer. These must be questions about user behavior, mental models, or needs — not product decisions.

Good examples:

• "Why do users abandon the checkout flow after entering payment information?"
• "How do first-time managers think about performance review conversations?"
• "What does the onboarding experience feel like for users who signed up via referral?"

Not research questions (these are decisions, not questions):

• "Should we redesign the checkout flow?"
• "Which feature should we build next?"
• "Is our onboarding working?"

If your research question starts with "should we," rewrite it as a question about user behavior or experience. Research informs decisions; it does not make them.

2. Research Goals and Business Context

What decisions will this research inform? Be specific about who needs to make a decision and what options they are choosing between. This section justifies the research to stakeholders and makes it easy to prioritize against other work.

Example: "This research will inform the product team's Q2 roadmap decision about whether to invest engineering capacity in checkout redesign, shipping improvements, or post-purchase communication. Without this research, we would be making a significant resource allocation based entirely on assumptions about where the friction is."

3. Methodology

Which research method will you use and why?

Choose based on your research question. If you want to understand why something happens, use interviews. If you want to measure how common an opinion is, use a survey. If you have never talked to users in this domain before, start with open-ended interviews before moving to any evaluative method.

4. Participant Criteria

Who will you recruit? Define:

• Core criteria: The essential characteristics every participant must have (e.g., "currently uses our product at least weekly")
• Behavioral criteria: What they must have done recently (e.g., "has completed at least one checkout in the last 60 days")
• Segment breakdown: If you need to compare groups, specify the split (e.g., "5 mobile users, 5 desktop users")
• Exclusion criteria: Who to screen out (e.g., "no current employees of direct competitors, no one from your own customer success team")

Be specific. Vague participant criteria produce recruiting that brings in the wrong people, which produces data that does not answer your question.

5. Timeline

When will each phase happen? Include:

• Recruitment opens: [Date]
• Recruitment closes / participants confirmed: [Date]
• Fieldwork (interviews/sessions): [Date range]
• Synthesis: [Date range]
• Findings readout: [Date]

Always build in buffer time. Recruiting almost always takes longer than expected. Synthesis is consistently underestimated — allow at least 1 hour of synthesis time per interview.

6. Sample Size

How many participants do you need?

General guidelines:

• Qualitative interviews: 5–10 per user segment. Research by Jakob Nielsen established that 5 participants uncover approximately 85% of usability issues. For discovery research, 8–10 provides high confidence in emerging themes.
• Multi-segment research: Apply the 5–10 guideline per segment. Testing two user segments means 10–20 participants total.
• Surveys: 100–300+ depending on your required margin of error and how many sub-groups you need to analyze.

For AI-moderated platforms like Koji, there is no incremental cost per additional interview, which means you can afford to run more and achieve higher confidence without budget pressure.

7. How Findings Will Be Used

What deliverable will you produce? Who receives it? By when? What decisions follow?

Example: "Findings will be delivered as a 20-minute research readout with accompanying summary document shared to the product, design, and engineering teams on [date]. The team will use these insights to finalize the Q2 roadmap in sprint planning on [date + 1 week]. The PM will document which research insights informed which roadmap decisions."

Specifying the downstream decision in your plan creates accountability — and increases the chance that research actually changes something.

The One-Page Research Plan

Here is the complete template:

---

[Project Name] Research Plan

Research Question(s): [1–3 questions about user behavior, needs, or experience]

Research Goals and Business Context: [What decisions will this inform? Who makes those decisions? What is the cost of getting it wrong?]

Methodology: [Method + rationale for why it fits the research question]

Participant Criteria:

• Core criteria: [...]
• Behavioral criteria: [...]
• Segments: [...]
• Exclusions: [...]

Timeline:

• Recruitment: [Date range]
• Fieldwork: [Date range]
• Synthesis: [Date range]
• Readout: [Date]

Sample Size: [Number] participants [across X segments]

How Findings Will Be Used: [Specific decision + team + date]

---

Key Things to Know

• Write the plan before recruiting: Do not start participant outreach before your plan is approved. Recruiting mismatched participants wastes everyone's time and delays the study.

• Share it before fieldwork begins: Get sign-off on the research questions from the stakeholders who will act on findings. This prevents scope creep and ensures alignment on what constitutes a good answer.

• Plans change — update them: If your research question shifts mid-project, update the plan and share the revision. A living document is better than a stale one that no longer reflects reality.

• One plan per study: If you have two distinct research questions, run two studies with separate plans. Trying to answer multiple questions in one study produces shallow answers to all of them.

• The plan is a communication tool: Its primary function is not organizational — it is communicative. It tells stakeholders what they will learn, when they will learn it, and what they will be asked to decide. Make it easy to read.

How AI Research Platforms Streamline Research Planning

Modern AI-powered research platforms have embedded much of the research planning process directly into the study creation workflow. In Koji, you describe your research goals in conversation with an AI consultant that helps you refine your research question, select the appropriate methodology, and structure your participant criteria — all before a single interview is conducted.

The research brief that Koji generates from this conversation functions as your research plan, visible to all team members before interviews begin. This creates natural alignment without a separate planning process. The time from "we should talk to customers" to "interviews are live" compresses from days to minutes.

This does not eliminate the need for explicit research planning — particularly the sections on business context, timeline, and how findings will be used. But it removes the most common bottleneck: deciding what to ask and how to ask it.

Tracking Research Impact Over Time

A research plan is valuable beyond the individual study. When you maintain a repository of research plans alongside their findings, you can:

• Track the ratio of research to roadmap decisions (are we doing enough research?)
• Link product outcomes back to original research questions (was the research right?)
• Identify gaps: domains where decisions are being made without supporting research
• Build institutional memory that survives team turnover

The goal is a research practice where every significant product decision can be traced to at least one piece of user research — and where research is consistently completed before the decision needs to be made, not after.

Tips & Best Practices

• Template your plan in a shared document that your whole team can access. Research should not happen in a silo.

• Create a research calendar that maps upcoming studies to your product roadmap milestones. Research should land before decisions, not after them.

• After each project, run a quick retrospective on your research plan: What questions did you end up not needing to answer? What did you wish you had asked but did not? Feed these lessons into your next plan.

• Keep all past research plans in a searchable repository. Teams regularly re-discover relevant prior research they had forgotten — saving weeks of repeated work.

Frequently Asked Questions

Q: How long should a UX research plan be? A: One page is ideal. The discipline of keeping it short forces clarity. If you cannot explain what you are studying and why in one page, your research question may not be sharp enough yet.

Q: Who should approve a research plan? A: At minimum, the team that will act on findings — typically product and design leads. For larger or riskier studies, add the product manager and any engineering lead affected by the likely outcomes.

Q: What is the difference between a research plan and a discussion guide? A: A research plan defines the project — what, why, who, when, and what happens after. A discussion guide defines the interview itself — the specific questions you will ask. Both are needed. Write the plan first; it directly shapes the discussion guide.

Q: Do I need a research plan for quick guerrilla research? A: Even a five-sentence note on what you are trying to learn and who you will ask is better than nothing. The habit of writing down your research question before starting — even informally — is worth building at every scale.

Q: How do I measure whether research influenced decisions? A: Add a "decision influenced" field to your research repository. Note which product, design, or strategy decisions referenced each study. Over time, this data shows whether your research practice is actually shaping the product or just producing interesting reports.