Project Management for User Researchers: A Simple Guide

As user researchers, we’re often asked to wear many different hats—playing and supporting a wide array of roles within a company. 

There have been many times where, while talking about a problem at work, I’ve been told: “You’re acting like a product manager again.” And while I am great at asking questions, I am definitely not a product manager.

If you find yourself in a similar position, or are a research team of one, you’re not alone in being asked to tackle tasks outside of your expertise. I’ve played a designer, a product manager, a business strategist and a (bad) developer. And I’ve learned one of the most effective ways to make yourself more valuable as a user researcher is to figure out how best to support these roles. 

Becoming more of a generalist helps you aid your teams when they need you the most—usually at the beginning phases of the project. If the beginning of a project is flawed, there’s a high likelihood that the outcome won’t be great either.

We’ll go over how to help teams develop well-thought-out, focused, and research-inclusive projects. By doing some of this groundwork, you’ll encourage stakeholders to regularly include research in their work. And when you expose them to that concept repeatedly, they’ll come to see how valuable user research can be on their own.

At the beginning of a project...

✔ Schedule regular catch-up meetings

I meet every two weeks with the product owner and designer of each team to make sure there aren’t any upcoming projects that are flying under my radar. This isn’t a long meeting, usually about 15-30 minutes—but it is just enough time to get informed on any upcoming projects, or to follow up on any recently finished projects. Not only does this help me ensure research will be included in relevant projects, but it also gives me time to recruit for any usability tests or generative research that needs to be done before or during design.

✔ Create a research plan

There are many wonderful things about a research plan. First, it clearly lays out the goals and objectives for the research project. A research plan prevents stakeholders from getting bogged down in the details, or switching the goal of the research in the middle of the project. Plans allow researchers to focus on the bigger picture and stay aligned on key objectives throughout the project, answering objectives efficiently.

Second, research plans get people involved in the research from the beginning, which really helps with buy-in. When colleagues have an idea for a research project, I give them a template to fill out. They then approach me with the completed plan. Not only does this get them thinking about how research could work, and why we would do research for a given project, but it also helps me understand their perspectives on the project.

✔ Create a kickoff document

After a research plan, I always help the teams create a kickoff document. This document helps the team think through the entire process of the project, in order to make sure we're all understanding and covering the essential “to-dos.” It is a wonderful way to start a project and to align on expectations.

Our kick-off document includes the following information:

✦ Executive summary

In a few sentences, this should describe what the project is about so anyone could read it and understand.

✦ Context

Details why the team is focused on that problem, and where the problem initially came from. It answers the following questions:

• As a customer, what is the core benefit? Why should I care?
• Why should we work on it?

✦ UX

This area is about the user experience, and goes into detail about what the different experiences might look like, including the MVP (minimum viable product) and other visions for the UX, such as...

• User flows
• User designs
• User stories

✦ RAID

Use a spreadsheet to outline the key pieces of the RAID system. Those are…

• Risks: Identify risks, root causes of the risk, and a risk response plan.
• Actions: Items you're tracking which must be completed by the core team.
• Issues: Risks that have been realized and are now being tracked as an issue with the issue owner. Plus: potential solutions, regular updates, and any lessons learned.
• Dependencies: Dependencies on other teams, tech work, or timelines. Include due dates, status, and owners of dependent work.

✦ Participants we're targeting

Describes the different participants this project will focus on, and gives everyone an understanding of why those participants are being screened.

✦ Success criteria

Explains what should be completed by the end of the project. This is incredibly important in understanding what the team defines as success, and what they want to accomplish by the end of the project.

✦ Project team

Lists the different team members and their respective roles in the project. This can also show what level of involvement each team member has in the project.

✦ Decision log

Outlines the decisions made by the team, so it’s easy to look back and understand what decisions were made and why.

✦ FAQ

Any questions that are frequently asked by external stakeholders, or the team, in order for people to read the document and feel fully informed.

Throughout a project...

✔ Use the same tools as your team

I used to fight against this. It made intuitive sense to me to present my research insights on the platforms that showcase them the most naturally. But that isn’t always the case.

Now, I make a point to adapt to the tools a team is using, and use those to house research insights. This makes it easy for them to find data, and to link it to other projects. Of course, I still make use of Google Slides, Sheets, and Slack because I find them helpful for presentations and housing more raw data, but I make sure the most important information is discoverable on shared tools.

✔ Put numbers on your research findings

Most of the research I do is qualitative, but it’s often helpful to embed some quantitative data to your research. On more data-driven teams, this makes insights appear more trustworthy and helps prioritize a course of action. Whenever I enter an insight into the tool I am using, I pull quantitative data to support it.

For instance, if I find users are having a difficult time filling out and understanding certain information on a form, I will take a look at the drop-off rate on that page. And I’ll list the number of people who mentioned the issue within the greater research project.

✔ Ground your insights in context

If there isn’t enough context or understanding around the insight, it’s difficult for a team to make decisions. A lot of times I see researchers struggle to have findings acted upon—usually because the information wasn’t robust enough. As researchers, we need to point out problems with enough supporting information (ie: videos, audio clips) and help teams come up with user-centric solutions. See my advice on making user research actionable.

✔ Continuously update the team

This is where the job can feel a bit like babysitting. You might do all the above but still find no one is responding to your research insights and requests. I have been in that boat, and it can feel like a sinking ship. Sometimes there isn’t anything for you to do, and you have to patiently continue posting insights and chasing colleagues. Instilling a company with a user research mindset takes time. I always make sure to deliver summaries catered to the team, with actionable points, and follow up with the designer to see if they need any help.

At the end of a project...

✔ Run a research retrospective

As researchers, we’re often asked to bring people together to ideate and brainstorm. Facilitation feels like a superpower we’ve acquired from having listened, empathized and remained (relatively) free from bias.

Often in an agile cycle, retrospectives can be full of venting and passing blame. It can be helpful for the team to have a moderator who can take a step back, and come from a more neutral place. 

✔ Get feedback from your team

Similar to the regular meetings I set with each team, I also make sure to host follow-up meetings. This could be a brainstorming session with a designer, where we sit at a whiteboard and sketch out different flows. It can be sitting with a product owner to discuss the complexity, feasibility, and business value of certain features.

I constantly ask them how I can improve my research delivery, or what additional resources they need from me. Primarily, I am there to help my team and want to provide value in the most tangible way for each stakeholder.

Wrapping it up

When it comes to the role of a user researcher, we can be jugglers and magicians. Although focusing on your main role is crucial, it's also powerful to look outside of your day-to-day responsibilities to see where you can help.

We hold a unique set of skills allowing us to help others, but also to grow our own knowledge and understand so much beyond the role of user research. When you’re able to facilitate effective projects as a researcher, you’re contributing beyond your core responsibilities to ensure your research makes a real impact.