Build a User Research Process That Respects Your Time and Boundaries

There are unlimited ways to execute your research—but how can you create a process that has less pitfalls along the way?

Words by Nikki Anderson-Stanier, Visuals by Thumy Phan

There are a lot of processes and frameworks out there when it comes to user research. For example, we have design thinking, lean user research, sprints, Jobs to be Done, and product development processes.

However, these different frameworks and processes are templates. Yes—there is a particular structure to them, but how often have you been in a situation where design thinking isn't applicable? Or where you are trying to conduct lean research, but recruitment is taking forever?

Asking the right questions

As a user researcher, what was my process? How did I execute different research projects? Which elements of design thinking did I mash together with product development phases? When did I throw away lean research for an in-depth study?

And what were my boundaries? Colleagues would frequently come to me with questions or requests that would break any templated process. There weren't answers to what to do if stakeholders didn't care about parts of the process or wanted the research to go quicker.

I soon realized that others would feel the same if I wasn't firm in my process and didn't understand my boundaries. As a result, I had a hard time compromising and making ad-hoc recommendations for changes in research plans.

So, I decided to solve this by building a research process just for me.

What is a research process?

Before diving into the exercise I did, I had first to establish what a research process meant. For me, it wasn't about building a framework for the company (although it certainly helped!). Instead, the research process was agnostic of where I was.

I wanted this research process to be something I could take with me anywhere, which was flexible but gave me a baseline of how I worked.

My goal was to have a go-to document where I could demonstrate and explain how I conducted research and my specific process each step of the way.

Creating a research process

I knew I had to start with a process that would apply to many companies. Since I tend to work in the digital space, I took the general product development process, which usually includes (with a million variations):

Discovery
Definition
Design
Development/implementation

I modeled my process after the product development process because I wanted something that stakeholders would be familiar with.

If I created an approach based solely on what I wanted to do as a researcher, it might not match the reality of how a product works at an organization. And this framework gave me a starting point rather than just sitting and staring at a blank page for hours.

After writing the four areas of the product development process, I realized I wanted to elaborate on some of them, so I chose the following stages:

Problem discovery - Looks at our users' problems and needs with a broader lens
Problem definition - Narrows the scope of the project to dive deeply into understanding a particular pain point or need
Design refinement - Helps us know if we are going in the right direction with solving that problem
Testing and execution - Allows us to decide on whether the solution is ready to launch
Measuring and monitoring - Enables us to measure the success of the solution and continue iterating on it based on feedback

Now, these don't always happen linearly. Sometimes if we have already done the research, we might skip to design refinement. Or if the product is live and we never set up success criteria, we might start with measuring and monitoring and then go back to design refinement if things need to change (or even to problem definition if we need a deeper understanding of the problem).

However, this process felt good for me, as it included all the steps I would go through in a project from beginning to end.

What to include in a research process

Now that I had my framework, like a journey map for research, I needed to fill in the different areas. At first I wasn't sure exactly what to include, so I returned to my goal.

This process aimed to include my approach to and boundaries of research at every step. What did I need to have in this document to achieve that goal?

After some brainstorming, I decided to include the following areas for each stage I detailed above:

The goal and what we were trying to achieve
Activities that happened before any actual research took place
Approximate timeline
Potential methodologies
Approaches to analysis
Ways to synthesize
Expected outcomes/deliverables
Post-research activities (activation)
How to lean out the stage (if necessary)
My boundaries

If I could detail this information in my process, I felt that I would approach research more confidently. In addition, this document would help me think through how to approach stakeholder requests and navigate projects more effectively.

Building the process (My example and a template)

After listing out the different areas I wanted to include in each stage, I built my process by filling in each section with how I have approached it in the past.

My example

I started with phase one, problem discovery. Despite my obsession and love for generative research, this stage was challenging. It took some time to articulate what I needed. Nonetheless, I forged ahead:

Phase one: Problem discovery

Goal: To discover the range of our users' problems and needs through a broad lens.

Pre-research activities

Intaking document when a request comes through and reviewing it with stakeholders to reframe any questions and properly scope the project
Assumption gathering workshop with stakeholders
Creating a research plan based on the intake document
Defining participant segments and planning recruitment
Creating success criteria to monitor later (if possible)
Kick-off meeting to align expectations, goals, and outcomes right before the project begins

Approximate timeline

Depending on the number of segments

1-2 segments: 6 weeks
For each additional segment, add 1-2 weeks

Potential methodologies

Secondary research

Desk research (ex: academic papers, market trends, or reviews/ratings)
Stakeholder interviews
Reviewing previous research
Reviewing other data sources (ex: customer support tickets)

Primary research

1:1 interviews
JTBD
Mental model interviews
Customer Journey interviews
Persona interviews
- Contextual inquiry
- Diary studies

Follow-up research

Surveys (ex: opportunity gap survey for JTBD)

Analysis:

If not done, transcribing the session
Creating tags
Tagging the transcript

Synthesis:

Grounded theory
Affinity diagrams (either by tags or goals of the research)
Debrief sessions with the team

Outcomes/deliverables:

Report (including video/audio, findings, and survey results)
Summaries of each session
Personas
Ecosystem maps
Journey maps
Job statements (ex: for JTBD)
Mental model diagrams

PS: Writing insights is tough. Check out this article for a model for writing compelling insights.

Post-research activities

Ideation session
How Might We statements
Usability movie night/usability bingo
Gallery days to view the deliverables
Co-creation meetings with the design to activate insights
Prioritizing insights with stakeholders (ex: using the RICE or KANO model)

How to lean out the stage

If there are too many segments to do in an appropriate timeline, prioritize 1-2 segments
Recruit while you conduct
Once clear patterns and trends emerge, stop the rest of the interviews (no fewer than ten interviews) OR send out the survey even if there are some interviews left (ex: send out the survey after 10 interviews)

My boundaries

No fewer than 12 participants per segment
The sample size for a survey must be correctly calculated
No more than three generative interviews a day
The team must be present for at least 50% of the debriefs
Analysis takes no less than five working days
If time runs out, pause the study entirely and go back to it later -> do not derive insights from the incomplete study

I went through and detailed every aspect I could think of for each stage. I then took a break and returned to it to see if I missed anything. This is because a living and breathing document that I iterated on as I developed more experience and learned how companies work.

I still included activities I didn't feel comfortable with, or methods I didn't know how to execute but highlighted them in a different color. Once I learned that method, I took away the color. This was also a great way to understand my growth and progress as a researcher.

As a note, I don't use every single one of these activities or methodologies for each project. Instead, this reminded me and gave me a list of things I need to (and can) do during each phase. Instead of thinking through all the different components necessary, it gave me a baseline.

This document helped me better articulate processes to my stakeholders and served me incredibly well during job interviews.

Get the template

Interested in walking through the exercise yourself? Make a copy of this template and use it for your upcoming planning.

Interested in other articles like this? Check out...

Nikki Anderson-Stanier is the founder of User Research Academy and a qualitative researcher with 9 years in the field. She loves solving human problems and petting all the dogs.

To get even more UXR nuggets, check out her user research membership, follow her on LinkedIn, or subscribe to her Substack.