User research is a tool to help us understand our users, their needs, behaviours, and attitudes. We need to know this so we can make informed decisions about the design and development of products and services for our clients.
When helping businesses develop a product or service, we can’t just walk into the nearest coffee shop, ask a few random people random questions, and call it user research. We need to focus our questions and ensure we’re getting the right information, from the right people, to make the right decisions.
Before speaking to any potential or current users, we need a user research plan. And we need to document it. But, it doesn’t have to take you weeks to put together. If you’re part of a product development team, most of the input you need may have already been created.
What is a user research plan?
A user research plan is really a blueprint for conducting research and should be tailored to the specific project and goals. I usually find myself creating a plan for each phase of a project—from discovery to development to post-launch, but there have been times when one plan for the entire project has sufficed.
Once I found my feet as Polymorph’s first full-time user researcher, I started focusing on the user research process a bit more. I really wanted to inspire all team members to have a research mindset and participate as much as they can. This meant I needed a user research plan template to help get everyone on the same page.
I found Nikki Anderson-Stanier’s How to Write a User Research Plan That Sets Your Project Up for Success. The template served as a great foundation because (1) I didn’t have to start from scratch, and (2) it showed me what I need in there to keep the team aligned. Over the last 3 years, I’ve tweaked it a bit, and it now plays a massive role in helping me organise my thoughts before I even start writing the recruitment screener and interview/survey questions.
The most important parts
I’ve kept most of the sections from Nikki’s template intact, with a few changes to align with our processes and the way we work with our clients.
1. Background
This section details why we are doing this research. What information do we need and how will it move us forward in building the right thing and building it right?
I use the following outputs from our project kickoff process in this section:
- The Product Market Fit Pyramid: This goodie from Dan Olsen’s Lean Product Playbook is a helpful (and memorable) way for us to visualise what we’re solving and who we’re solving it for. And as an added bonus, it provides most of the information needed for the research objectives and participants sections in the plan. I’ll get to that soon 😀
- The Product Vision: This is the long-term goal for the product. It describes what the product will become and how it will be used.
- The Product Strategy: Basically, our plan for achieving our product vision. It outlines the steps that we’re taking to bring the product to market and make it a success.
- Our Objectives and Key Results (OKRs): This is how we’ll measure the success of the product and, ultimately, the metrics that matter the most to the whole team. Tying the research insights back to these metrics has helped me show the value of investing time in speaking to users.
Product Market
Fit Pyramid
- Identify specific needs within a good market
- Look for needs that are not adequately met
- Where you may be able to
serve these needs better than the competition
Product Market Fit Pyramid
2. Research objectives
This section essentially drives the entire research project.
I include a very useful Mad Lib I learned from Nikki (she has a wealth of great resources and is worth a follow) in this section. It helps focus the research questions. It goes like this…
We need (information) to move forward with (decision). This decision is important because it will impact ______.
I complete this with all key stakeholders to ensure we’re all aligned on what we need to get out of this research.
Next up, I list questions that we need to have answered by the end of this research. These should help us address a gap in our current knowledge and/or validate our riskiest assumptions.
When we’re in the product discovery phase, I look at the product vision and the information on the product-market fit pyramid to help focus on our most important questions.
3. Participants
We need to talk to the right people to get the right information to move the team in the right direction. I grab this from the ‘target audience’ section on the product-market fit pyramid and write a screener, which I add in this section.
If we’re doing this round of research to find out who the target audience is, I do the following to help me pin-point who to speak to:
- Talk to internal stakeholders who may have a good idea of what the target user will look like and create hypotheses about their attitudes and behaviours
- Look at competitors, and recruit based on their audiences.
4. Methodology
In this section, it is important to briefly discuss the selected methodology and the reasons why it was chosen.
Overall, the research methodology should:
- align with the research objectives
- be appropriate for the target audience and the research context
- be realistic and feasible given the available resources
- protect the rights and welfare of participants
5. Discussion guide
A discussion guide is useful when conducting face-to-face interviews with users. It’s my reminder of the questions that will help us achieve our research objectives and keep the conversation on track.
If we’re doing longitudinal or unmoderated research, such as unmoderated usability testing or diary studies, this section can include specific prompts or activities for participants to complete.
Even if I don’t use the guide during the actual interviews, having one creates the opportunity for other team members to add questions they need answered.
Sarah Doody created a great list of starter questions to draw inspiration from.
6. Timeline
Here I give a rough project timeline, from recruiting to presenting the insights. This helps the team highlight any potential bottlenecks or dependencies in the project timeline. I make sure to schedule key sessions where team members are needed beforehand once everyone has agreed on the timeline.
7. Resources
In this section, I make sure it’s easy for everyone to find links to any resources that would give context to the study, such as recordings, notes, synthesis documents, the debrief presentation, prototypes, etc.
