How to Write a User Research Plan That Sets Your Project Up for Success

When we think about what we love about our work—what excites us, what inspires us, what triggers the next big “a-ha” moment—we rarely think about processes or documentation.

But when we think about what frustrates us about our work—”next steps” that get delayed, projects that feel unfocused, little logistics that hold up our plans—we often blame processes and documentation.

Even if you don’t consistently reference a research plan, it can help ensure your next project goes more smoothly.

This walk-through will teach you how to write a plan in 15 minutes that’ll save you hours of work down the road.

Get our time-saving research plan templates (with a sample plan, and handy walkthrough) for free here. 

Jump to:

• Why you need a research plan
• The 7 key components
  • Part 1: Background
  • Part 2: Objectives
  • Part 3: Participants
  • Part 4: Methodology
  • Part 5: Interview Guide
  • Part 6: Approximate Timeline
  • Part 7: Resources
• Conclusion
  

What do you mean by user research plan? And why do I need one?

A user research plan is a concise reference point for your project’s timeline, goals, main players, and objectives. It’s not always used extensively after the project has started. But sometimes you'll use it to remind stakeholders of a project’s purpose, or explain certain logistical decisions (like why certain types of participants were recruited).

Overall, research plans offer an overview about the initiative taking place and serve as a kick-off document for a project. Their beauty lies in their capacity to keep your team on track, to ensure overarching goals are well-defined and agreed upon, and to guarantee those goals are met by the research.

Research plans keep the entire team focused on an outcome and provide an easy reference to keep “need-to-know” stakeholders in the know. They prevent everyone from getting bogged down in the details and from switching the goal of the research in the middle by mistake.

Most importantly, they allow researchers—or whoever is doing the research—to ensure the objectives of the research plan will be answered in the most effective and efficient way possible by the end of the project. We want to make sure we are actually answering the questions we set out to uncover, and research plans enable us to do so.

Back to top

The 7 core components of a user research plan:

1. The background of the research project detailing why we are conducting this study. This can also include the internal stakeholders involved.
2. The objectives and goals of the research, what the teams want to learn from the research, or what they would like the outcome to be. I think about objectives this way: We should be able to answer all the objectives at the end of the research project.
3. A breakdown of the participants we are recruiting and how we are recruiting them.
4. How we are conducting the research, which includes the chosen research method.
5. An interview guide as a cheat sheet of instructions/questions to follow during the research session. This includes components within itself, such as the introduction, interview questions and conclusion.
6. An approximate timeline of when the research will take place, and when a report could be expected.
7. Resources for people to find, such as links to any other documentation.

An an example project:

Imagine you’re working as a researcher at an online food ordering service that allows you to order takeaway delivered to your door from restaurants in your area.

One day, a project lands on your desk. A product manager wants to know how to get people to order takeaway more frequently.

After some back and forth, you get a handle on what the product team is hoping to learn. Their goal is to increase retention rates and user satisfaction. They want to know: Why do customers not order more frequently? And how do customers decide what they want to order?

The team wants to have a better overall understanding of the drivers for customer loyalty, and the pain points that prevent customers from becoming loyal to the platform.

With the project in hand, you’re ready to sit down and write a plan. Then you can share the first draft with the product team to ensure you’re interpreting their aims correctly.

Back to top

Part 1: Background

The background section is pretty straightforward. It consists of a few sentences on what the research is about and why it is happening, which orients people to needs and expectations. The background also includes a problem statement (the central question you’re trying to answer with the research findings).

Example background

We want to understand the reasons behind why certain customers are reordering at a higher frequency, as well as the barriers encountered by customers that prevent them from reordering on the platform (problem statement).

We will be using generative research techniques to explore the journey users take—both inside and outside of our platform, when they decide to order takeaway—in order to better understand the challenges and needs they face in these circumstances. 

Back to top

Part 2: Objectives

Objectives are one of the hardest parts of the research plan to write. They’re the specific ideas you want to learn more about during the research and the questions you want to be answered. Essentially, the objectives drive the entire project. So, how do you write them effectively?

First, start with the central problem statement: to understand the reasons behind why certain customers are reordering at a higher frequency, as well as the barriers encountered by customers that prevent them from reordering on the platform.

Our research objectives should address what we want to learn and how we are going to study the problem statement.

Example objectives

• Understand how and why users are currently reordering food on our website/app
• Discover users’ motivations behind reordering, both inside and outside of the website/app
• Uncover other websites/apps customers are using to order takeaway
• Learn about any pain points users are encountering during their process, and what improvements they might make

Bad versus better objectives:

Here are some additional examples I have generated in order to exemplify good versus bad objectives.

Example 1

Bad: Understand why participants order food.

Better: Understand the end-to-end journey of how and why participants choose to order food online.

Why: “Understand why participants order food” is still too broad. It feels more like a problem statement that you’d want to break down into further objectives. You haven’t set a direction or boundaries.

Example 2

Bad: Find out how to get participants to order food online.

Better: Uncover participants’ thought processes and prior experiences behind ordering food online.

Why: Trying to learn how to make someone do something is a challenging perspective with which to go into research. How would we ask good questions to get that information?

We are more interested in seeing what their thought process is behind the process, and if/why they have done so in the past. That’s a better foundation to build from.

Example 3

Bad: Find out why people use Postmates to order food.

Better: Discover the different tools participants use when deciding to order food, and how they feel about each tool

Why: This could be helpful if Postmates is a tool your users frequently use instead of your platform, and you’re setting out to do a competitive analysis.

However, in this case, we’re doing generative research—defined by the product team’s needs and the plan’s background statement.

So in this case, it’s more useful to rely on the research to uncover what kinds of other tools are used. Otherwise, you’re hyper-focused and might miss other opportunities to explore.

Back to top

Part 3: Participants

Now that we’ve defined our problem statements and objectives, it’s time to define the type of participants we’ll rely on to get the insights we need.

One of the most important elements to any project is talking to the right people. If you don’t have a set vision for who you want to recruit, approximate your user, and include that approximation in your plan.

This will help optimize recruiting efforts to ensure you have the best participants you need for your study. Here are a few ways to approach this:

Allot a day to sit in a room and define your target user

Bring in internal stakeholders that may have a good idea of what the target user will look like (such as marketing, sales, and customer support). With these stakeholders you can create hypotheses about who your users are, which is a great starting point for who you should be talking to.

Look at competitors similar to you

Recruit based on their audiences. You can even recruit people who use the competitor's product and, during the interview, ask them how they would make it better.

Write a great screener

This will get you the participants you need.

• Is there a particular behavior you are looking for (such as ordered takeout X# amount of times in the past three months)?
• Is it necessary they have used your product (or a competitor’s product)?
• Do they need to be a certain age or hold a certain professional title?
  

Make sure you include the right criteria in order to evaluate whether or not that person would be your target participant.

It’s often useful to attach your screener questions to this part of the plan.

Back to top

Part 4: Methodology

Compared to the others, this step is fairly easy. In this section, talk briefly about the chosen methodology and the reasons behind why that particular method was chosen.

Example methodology

For this study, we’re using one-on-one generative research interviews. This method will enable us to dig deeper into understanding our customers, fostering a strong sense of empathy and enabling us to answer our objectives.

Back to top

Part 5: Interview Guide

If you’ll be talking to your users in real time, an interview guide is a valuable cheat sheet. It reminds you of which questions will help you meet your objectives, and can keep your discussions on track.

If you’re doing longitudinal or unmoderated research—like unmoderated usability testing, or a diary study—your interview guide might include the exact prompts or triggers you’ll be sending your participants to complete.

Even if you don’t actively refer to your interview guide, writing one ensures everyone else on the team has a place to input their questions. And if you’re outlining questions or prompts for unmoderated research, making those questions public for reference gives your team a chance to alert you if something is unclear.

For moderated research, my interview guides consist of the following sections:

1. Introduction
2. Questions
3. Wrap-up

1. Introduction

The introduction details what you will say to the participant before the session begins, and serves as a nice preview of all the different points you’ll be discussing. It’s especially helpful if you are nervous about going into a session.

Example introduction

Hi there, I’m Nikki, a user researcher at a takeaway delivery company. Thank you so much for talking with me today. I am really excited to have a conversation with you!

During this session, we are looking to better understand what makes you order food from our service. Imagine we're filming a small documentary on you, and are really trying to understand all your thoughts. There are no right or wrong answers, so please just talk freely, and I promise we will find it fascinating.

This session should take about 60 minutes. If you feel uncomfortable at any time or need to stop/take a break, just let me know. Everything you say here today will be completely confidential.

Would it be okay if we recorded today’s session for internal notetaking purposes? Do you have any questions for me? Let’s get started!

2. Questions

This portion of the interview guide is the trickiest to write. In this section, we’re writing down some of the open-ended questions we want to ask users during the session.

For most types of qual research, you won’t always have a long list of detailed questions, since it’s more of a conversation than an interview. But readying a few open-ended questions you can then follow up on can serve as useful prep.

Pro tip: Questions to avoid in your interviews and interview guides

• Priming users – Forces the user to answer in a particular way
• Leading questions – May prohibit the user from exploring a different avenue
• Asking about future behavior – Instead of focusing on the past/present
• Double-barreled questions – Asking two questions in one sentence
• Yes/no questions – Ends the conversation. Instead, we focus on open-ended questions

Examples of priming/leading questions:

• Priming: “How much do you like being able to order takeaway online?”
• Leading: “Could you show me how you would reorder the same order by clicking on the button?”

I always outline my interview guide questions with the TEDW approach. TEDW stands for the following structures:

• “Tell me…”
• “Explain….”
• “Describe….”
• “Walk me through….”

Beyond that, one cool trick for question generation is to use your research objectives. Your questions should be able to give you insights that answer your objectives.

So when you ask a participant a question, it is ultimately answering one of the objectives. Turn each objective into 3–5 questions.

Developing example questions

So, let’s take our central research problem and objectives and form some research questions.

Central research problem: To understand the reasons behind why certain customers are reordering at a higher frequency, as well as the barriers encountered by customers that prevent them from reordering on the platform.

Objectives

• Discover users’ motivations behind reordering, both inside and outside of the website/app
• Uncover other websites/apps customers are using to order takeaway
• Learn about any pain points users are encountering during their process, and what improvements they might make

Research questions

Objective 1: Discover users’ motivations behind reordering, both inside and outside of the website/app

• Think about the last time you ordered takeaway on our website/app. Walk me through the entire process, starting with what sparked the idea.
• Explain how you made the decision to reorder food on our particular website/app.
• Describe why you decided to reorder takeaway rather than cooking your own dinner and/or going out to eat.
  • Who were you talking to?
  • What time of day was it?
  • How were you feeling?
  • Did you have other websites/apps open?

Objective 2: Learn about any pain points users are encountering during their process, and what improvements they might make.

• Describe the last time you struggled with reordering food, what was that like?
  • How did you solve the problem?
• What would be the most ideal scenario for reordering takeaway from the website/app (crazy ideas included!)?
• How would you change or improve the process of reordering food outside of our website/app? Inside our website/app?

Objective 3: Uncover other websites/apps customers are using to order takeaway.

• Talk me through the other websites/apps you have used multiple to order takeaway (or even groceries).
• Describe your experience with these other websites/apps.
• What are the other websites/apps you use to help you make a decision about whether or not to order takeaway?

Each of these research questions is a jumping off point for a more open conversation. They get at the core of your objectives, which in turn gets to the core of the central problem you’re trying to solve.

3. Wrap-up

The wrap-up is a reminder of all the items to mention during the end of an interview. Generally, you cover information such as compensation, asking if they would be interested in future research, and assuring them that you’re thankful for their time.

Example wrap up

Those are all the questions I have for you today. I really appreciate you taking the time. Your feedback was extremely helpful, and I am excited to share it with the team to see how we can improve.

Since your feedback was so useful, would you be willing to participate in another research session in the future? You have my direct email, so if you have any problems with the compensation or any questions or feedback in the future, please feel free to email me at any time.

Do you have any other questions for me? Again, thank you so much for your time and I hope you enjoy the rest of your day!

Back to top

Part 6: Approximate Timeline

I place an approximate timeline in my research plans, so people know what to expect for start and end dates.

Some researchers stay away from this timeline, as it can solidify a deadline that may prove more difficult to meet than expected. I always stress that it is a basic approximation.

Example timeline

• Research start date: Monday, August 5th
• Research plan creation and review: Wednesday, August 7th
• Recruitment begins: Thursday, August 8th
• Interviewing begins: Thursday, August 15th
• Interviewing ends: Friday, August 23rd
• Synthesis begins: Monday, August 26th
• Synthesis ends: Wednesday, August 28th
• Report presentation: Friday, August 30th
  

Back to top

Part 7: Resources/Links to Documentation

In this section, I make sure it’s easy for everyone to find:

• Links to the research sessions
• Any synthesis documents
• Notes
• The presentation
• Any development/design tickets, prototypes or concepts
• Any follow-up information which would give context to the study

Back to top

Summing it up: 

Your user research plan is your research project in miniature. It’s the simplest way to align expectations, solicit feedback, and generate enthusiasm and support for your study.

Whether it actively guides your interviews, or just provides an active structure for organizing your thoughts, a solid research plan can go a long way towards guaranteeing a solid research project.

Back to top

Interested in more articles like this?

• See how the team at Credit Karma set up journey mapping as a tool for cross-functional research
• Explore our cross-team collaboration series, starting with user research and account management
• Activate your insights and keep your research from being shelved with this IMPACTS Framework