Build a User Research Process That Respects Your Time and Boundaries

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?

Jump to a section:

• Asking the right questions
• What to include
• Building the process
• Get the template

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:

1. Problem discovery - Looks at our users' problems and needs with a broader lens
2. Problem definition - Narrows the scope of the project to dive deeply into understanding a particular pain point or need
3. Design refinement - Helps us know if we are going in the right direction with solving that problem
4. Testing and execution - Allows us to decide on whether the solution is ready to launch
5. 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:

1. The goal and what we were trying to achieve
2. Activities that happened before any actual research took place
3. Approximate timeline
4. Potential methodologies
5. Approaches to analysis
6. Ways to synthesize
7. Expected outcomes/deliverables
8. Post-research activities (activation)
9. How to lean out the stage (if necessary)
10. 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...

• Time Management for User Researchers: Tips for Sanity, Productivity, and Impact
• Effective Remote Project Management for Experience Researchers: Three Tactics for Impact (& Sanity)
• Project Management for User Researchers: A Simple Guide