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.
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.
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.
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?
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,
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
- Dependencies: Dependencies on other teams, tech work, or timelines. Include due dates, status, and owners of dependent work.
✦ Participants we're targeting
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.
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.
As researchers, we need to point out problems with enough supporting information (ex: videos, audio clips) and help teams come up with user-centric solutions.
✔ 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.
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.