User research plans: who cares and how to write one [with template]
Research plans are something I absolutely swear by. I have been writing them for years and, at this point, I don’t think I could actually start a project without first creating a research plan (that may be a slight exaggeration, but it is mostly true). For me, they contain all of the necessary information about the research project, and really ensure the whole team is aligned in the right direction. In the past, they have really acted as a North Star in my projects.
What is a user research plan?
A user research plan is a form of documentation, which is why some people may shy away from it. I can honestly say, it is not referenced or used often, after the project has started, unless to point out a specific reason why we are conducting the study, or why we recruited certain types of participants.
Overall, they are an explanation about the research initiative taking place, serving as a kick-off document for a project, and really boil down to what the goal of the research project is.
Why do we create them?
User research is super exciting, to me at least, and it can be really easy to get off topic during a research project. Say you start a 3 week project with the intention to better understand your users through generative/discovery research and, suddenly, two weeks in, you realize the majority of the time is spent asking questions that the team is interested in and tacking on prototypes to the end of these sessions. Soon enough, your generative research hour-long session has turned into a mash-up of different subjects and Invision links. I’ve seen this happen a lot.
This doesn’t mean we can’t answer all these exciting questions, or test all these prototypes. What I do mean is we can do them, just separately. I have watched researchers try to mash too many things together at once and the results are confusing, at best. Albeit, sometimes I will add a simple prototype to the end of a session, but never more than two. It becomes extremely disorienting for your users to test a bunch of different concepts at once. This is where a well-crafted research plan comes into place,
Research plans keep everyone on track and make sure the overarching goals are well-defined and will get answered by the research. They keep the entire team aligned on the outcome, the bigger picture, instead of getting bogged down in the details, or switching the goal of the research in the middle, by mistake. Most importantly, they allow researchers (or whoever is doing the research) to really focus, and make sure 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.
How to structure a research plan
For a while, when I first started writing these, they felt way too formal and too much like all the papers I used to write in academia. They can definitely have that sort of feeling about them, but are much lighter on the information. Usually, I don’t have more than a few sentences or bullet points for each section. The only time-consuming section will be the interview guide, which we will explore more.
- Background — a few sentences on what the research is about and why it is happening, which helps get people on the same page as to why this research is recurring, and what we hope to understand at the end. Arguably, this part is the most important for teams to align on first
- Stakeholders involved — the relevant internal team members who will be impacted by this research, and, potentially, the teams that initially came up with the research initiative
- Research objectives — what the teams want to learn from the research, or what they would like the outcomes to be. I like to put objectives this way: we should be able to answer all the objectives at the end of the research project, so, whether we are looking to understand an end-to-end journey or evaluate a new set of features, we should be able to come to conclusions about these objectives at the end. Read about how to write and elevate your research objectives here
- Methods — choose which research methods should be used in order to answer the research objectives. Mostly I am choosing between more generative methods in order to uncover motivations or broader insights, or usability testing to evaluate a current product or prototype
- Business objectives (optional, but recommended) — this is where you can discuss what business KPIs might be impacted through this research project, such as revenue, retention, acquisition, etc.
- Participants — who are the participants you are targeting for this particular project, such as demographics, geography, non-users versus users
- Interview guide — a cheat sheet containing topics/questions to follow during the interview
- UX Metrics (more applicable for usability tests) — what criteria would determine success, such as time on task or task success for a usability test
- Timeline — a general overview of how long the research will take
Gathering this information will require you to talk to other people, like product owners, developers or designers, which I always highly recommend doing. I ensure we are creating the plan together so that, before we start the project, I am convinced everything makes sense, and we are on the same page. Oftentimes, I will gather what they are interested in, or the questions they want asked, and turn them into more unbiased alternatives.
An example (and template)
Although I have a template available, I will use an example for context and to make this less abstract. Imagine you worked at a Homemade Dog Food App Company, and recently discovered that the team was interested in learning more about how people use the app to order dog food, and why they use this app over others.
Background:
For this particular research project, we are very focused on two main areas: 1. We want to understand the motivations behind why our customers order dog food on this app, and on others, and to gather a deep understanding of the journey people go on from when they think of this need, to when they are feeding their dogs; 2. We are interested in learning how customers currently use our product, and any pain points or problems they are experiencing
Stakeholders involved:
Retention team: product owner(s), designer(s), developer(s)
Acquisition team: product owner(s), designer(s), developer(s)
Method(s):
20 60 minute interviews, split between:
- Usability discovery (‘walk the store’) sessions
- Jobs To Be Done sessions
- Post-qualitative surveys on importance of features and concepts found in qualitative data
Research objectives:
- Discover people’s end-to-end journey when considering, purchasing and using dog food
- Uncover the current process people undergo when considering, purchasing and using dog food on this particular app
- Identify the competitive landscape of what additional products customers are currently using, and why
- Evaluate the current product, and any immediate pain points, or bugs, customers are facing
Business objectives:
- Customer retention rate
- Customer satisfaction rate (measured by: System Usability Scale)
- Users creating an account & logging in
- Understand competitors
Participants:
n=20
- 10 current users
- 10 non-users
- Male/female mix
Interview guide
This is it’s own topic itself, which we will cover in a future article, but the basic premise here is to include some potential questions you would ask during the interview. I usually tell people to form interview questions using the TEDW method, as they tend to open up conversation in an unbiased way. Below is the TEDW question method:
- “Tell me more…”
- “Explain…”
- “Describe what you mean by…”
- “Walk me through…”
UX Metrics
- Evaluation and decrease in the amount of bugs found in the product
- UX improvements for pain points, including potential prototypes which should be user tested
- JTBD statements and desired outcomes
- Personas and customer journey maps (even if wireframes)
Timeline
Approximately 4–6 weeks for recruitment, qualitative research, analysis, surveying and quantitative analysis
Create your own
Not only do I write research plans at the beginning of each project, which keeps the team really on track, but they are also a great tool to share and teach to colleagues. At my most recent position, I have been encouraging product owners to structure a draft of their own research plans before they come to me, which really prompts them to think about the questions they want to be answered, and the expected (or desired outcome). It has been a wonderful way to evangelize research throughout the company, and get people really thinking about user research.
If you are interested in writing your own, feel free to use my template (updated!), and let me know what you think, including any areas that seem unclear or unnecessary!
Interested in more user research? I teach an Introduction to User Research Course and am available for one-on-one mentoring. Check out the User Research Academy.
Please join the User Research Academy Slack Community for more updates, postings, and Q&A sessions