UX Research Plan: Template, 6-Week Timeline and Example
8 min read ยท 2026-10-25
A UX research plan is a short document that states what you want to learn, why it matters to the product, which method you will use, who you will talk to, when it happens and how the findings will be used. It keeps the study focused, gets the product team to agree on scope before sessions start, and makes it clear which decision the research will inform.
Most templates stop at the one-page plan. This guide also gives you a six-week study timeline with milestones, a filled-in example for a B2B onboarding study, the roles around a study, how to choose a method and how to share findings so the team acts on them. It works for a dedicated researcher, a product designer doing their own research or a product manager running interviews.
The roadmap at a glance
Goal: Answer the study's research questions with evidence from real users and turn the findings into decisions the product team has agreed to act on. Duration: 6 weeks
Frame the study (Week 1)
Agree on the decision the research must inform and the questions it must answer.
- Meet the product manager, designer and engineering lead to name the decision at stake, such as which onboarding flow to build.
- Collect what is already known: past research, support tickets, analytics and sales call notes.
- Write three to five research questions that are specific and answerable.
- Set what is in and out of scope for this study.
Milestone: One-page research plan draft with the decision, questions and scope, reviewed by the product trio.
Design the method (Week 2)
Choose the method and prepare the materials that will answer the questions.
- Pick the method that fits the questions: interviews, usability testing, a diary study, a survey or a mix.
- Write the screener with the criteria that define a good participant.
- Write the discussion guide or test script, with tasks and follow-up prompts.
- Prepare consent forms and decide how recordings and notes will be stored.
Milestone: Plan approved by the product manager, with screener, discussion guide and consent form ready.
Recruit participants (Weeks 2-3)
Book the right people, not just the available ones.
- Choose the source: your customer list, a panel, the customer success team or an in-product intercept.
- Screen candidates and book sessions, with one or two extra in case of no-shows.
- Send calendar invites, reminders and any prototype links.
- Run a pilot session with a colleague to test timing and the guide.
Milestone: All sessions booked with screened participants and the guide adjusted after the pilot.
Run sessions (Weeks 3-4)
Collect clean, comparable data across all sessions.
- Run sessions with one moderator and one note-taker, and invite product team members to observe.
- Hold a short debrief after each session to capture the top observations.
- Tag notes in your repository or a shared board as you go.
- Adjust the guide only between sessions, and record what changed.
Milestone: All planned sessions completed, with notes and recordings stored and tagged.
Analyze and synthesize (Weeks 4-5)
Turn raw observations into findings that answer the research questions.
- Cluster observations into themes with the team in an affinity mapping session.
- Write each finding as a clear statement with supporting evidence from several participants.
- Rate findings by how often they appeared and how much they affect the user's goal.
- Link each finding back to a research question.
Milestone: Findings document with each research question answered or marked as open.
Share and decide (Week 6)
Get the team to act on the findings.
- Run a readout with the product trio and stakeholders, using clips and quotes from sessions.
- Hold a working session to turn findings into recommendations, each with an owner.
- Add agreed changes to the product backlog or roadmap.
- Store the plan, findings and recordings in the research repository.
Milestone: Readout held and recommendations accepted, each with an owner and a backlog item.
What goes in a UX research plan
Keep the plan to one or two pages. Its readers are busy product managers, designers and engineers who need to agree on the study, not read a thesis. A short plan also makes it easy to reuse the structure for the next study.
These are the parts most plans need, in this order.
- Background: what prompted the study and what is already known.
- Decision to inform: the product decision this research supports.
- Research questions: three to five specific questions the study will answer.
- Method: what you will do and why it fits the questions.
- Participants: who, how many, how you will recruit them and any incentives.
- Timeline and owners: key dates and who does what.
- Outputs: what you will share, with whom and when.
How to choose the right method
Start from the research question, not from the method you like most. Questions about why people do things, or what they need, call for interviews or field studies. Questions about whether people can complete a task call for usability testing. Questions about how many people share a behavior call for a survey or analytics.
A useful rule of thumb: qualitative methods tell you what is happening and why, quantitative methods tell you how much or how often. Many studies combine both, such as interviews to find the problems and a short survey to size them. Name the method in the plan and say in one sentence why it fits.
- Generative interviews: understanding needs, workflows and pain points before you design.
- Usability testing: checking whether people can complete key tasks on a prototype or live product.
- Diary study: seeing behavior over days or weeks, such as how people use a product at work.
- Survey: measuring attitudes or behaviors across many users.
- Card sorting or tree testing: shaping or checking navigation and information structure.
Example: a research plan for a B2B onboarding study
Picture a project management software company where many new workspaces are created but few invite teammates in the first week. The product manager wants to know whether to redesign onboarding or add a guided setup.
Here is the plan filled in, with an owner and a milestone for each step.
- Decision and questions (owner: product manager with the UX researcher): decide between a redesigned onboarding and a guided setup. Questions: what are new admins trying to do in their first session, what stops them from inviting teammates, and what would make them confident to roll the tool out to their team? Milestone: plan approved in week 1.
- Method and recruitment (owner: UX researcher): eight remote interviews with admins who signed up in the last month, half who invited teammates and half who did not, recruited from sign-up data with help from customer success. Milestone: sessions booked by week 3.
- Sessions (owner: UX researcher, with the designer as note-taker): 45-minute calls with a walkthrough of their workspace, engineering lead observing two sessions. Milestone: eight sessions done by week 4.
- Synthesis and readout (owner: UX researcher and product designer): affinity session with the product trio, findings show admins hesitate to invite until templates match their process. Milestone: readout in week 6, with template setup added to the next quarter's roadmap.
Who owns what
Research findings get used when the people who make the decisions take part in the study. Write the roles into the plan and invite stakeholders to at least one or two sessions.
In smaller teams one person may hold several roles. That is fine, as long as someone owns each one.
- UX researcher or research lead: owns the plan, method, moderation, analysis and readout.
- Product manager: names the decision, approves scope and turns findings into backlog items.
- Product designer: helps write tasks, takes notes, joins synthesis and designs the response.
- Engineering lead: observes sessions and flags technical limits on possible solutions.
- Customer success or sales: helps recruit participants and shares context on accounts.
- Research operations, if you have it: handles recruiting, incentives, consent and the repository.
How to share findings so the team acts on them
A long report sent by email rarely changes a roadmap. Run a live readout of 30 to 45 minutes. Open with the decision and the research questions, then give one slide per key finding: the statement, two or three supporting quotes or short clips, and how often it came up. End with recommendations and a clear ask.
For leadership, cut it to one slide: the decision, the top three findings and what the team will do next. Keep raw notes and the full analysis in the repository for anyone who wants detail. Check back after a few weeks to see whether the recommendations made it into the backlog, and report that in your next study plan.
From one study plan to a research roadmap
A single plan covers one study. A research roadmap covers the studies you plan for the quarter or half-year, lined up with the product roadmap. Each row is a study with its decision, method, owner and target dates. Studies that inform big bets go first. Ongoing work, such as monthly usability tests on new features, sits in its own lane.
Review the research roadmap with product leads at quarterly planning. Drop studies that no longer inform a decision, and add ones for new bets. This keeps research ahead of design and engineering instead of trying to catch up after a feature has shipped.
Common mistakes to avoid
- Writing vague goals like understanding users leads to findings nobody can act on, so tie the plan to one product decision and specific research questions.
- Recruiting whoever is available skews the results, so write a screener based on behavior, such as recent sign-up or task frequency.
- Asking users what features they want gives unreliable answers, so ask about past behavior and watch them work instead.
- Running sessions without stakeholders makes findings easy to dismiss, so invite the product manager and engineers to observe at least one or two.
- Changing the discussion guide mid-session makes sessions hard to compare, so test it in a pilot session and adjust only between sessions.
- Ending with a report and no follow-up means findings are forgotten, so agree on recommendations with owners in a working session after the readout.
Frequently asked questions
What should be included in a UX research plan?
Include background, the decision the study informs, three to five research questions, the method, participants and recruitment, a timeline with owners, and the outputs you will share. Keep it to one or two pages.
How many participants do I need for a UX study?
It depends on the method. Many teams run five to eight sessions per user group for qualitative interviews or usability tests, and add more if they study several distinct groups. Surveys need far larger samples to support numbers.
How long does a UX research study take?
A focused interview or usability study often takes four to six weeks from plan to readout. Recruiting is often the slowest step. Smaller rapid studies with existing participants can run in one or two weeks.
What is the difference between a UX research plan and a research roadmap?
A research plan covers one study: its questions, method, participants and timeline. A research roadmap lines up several studies over a quarter or more, matched to the product roadmap and the decisions coming up.
Who should approve a UX research plan?
Usually the product manager who owns the decision, with input from the designer and engineering lead. In larger teams, a research lead may also review the method and recruitment approach.