Conducting user research is only one part of the job. When I started as a user researcher, I thought I would be running around scheduling, interviewing, and presenting. I was right, but I didn't also know I would be creating a culture of user research at every organization I joined.
Throughout the years, I’ve realized that it isn't just about doing the research. We have to be more thoughtful about creating a research-friendly environment, balancing types of research, and including colleagues throughout our research process. In my experience, when I’ve joined organizations, I’ve often been the first or only user researcher. This meant creating a research framework and culture that made colleagues excited about how I could help and what value I could bring.
Start with a framework
If people don't understand what you do, they won't know when, how, or why to come to you. When introducing user research to an organization, the best thing I have done is creating a user research framework. In this document, I detail everything anyone could want to know about user research at our organization. Not only does this save you time from responding to the same questions repeatedly, but it is also an excellent onboarding document for new researchers or people who will be interfacing often with research.
Here are the components I typically include in a framework deck:
What is user research? This details the basics of user research, what it means, and why we conduct user research, and the different user research methods you use at your organization.
Misconceptions of user research. This section highlights the common misconceptions of user research (e.g.: too slow, too expensive) and how to combat those misconceptions or issues.
Value of user research across different departments. This section highlights how user research can positively impact different departments (e.g.: how I can help product managers or marketing achieve their goals), and how user researchers can help these departments get answers to their customer questions.
UX research principles & mission. Under this section, you would detail the mission you want to achieve with user research, and the principles you (or your team) will follow as user researchers.
UX research responsibilities. This section details the exact responsibilities of a user researcher (e.g.: recruitment, debriefs, synthesis) and can also detail where others can support (e.g.: note taking).
UX research process. This section details the user research process at your organization and, ideally, is a step-by-step process of how and when people should reach out to you, and what they can expect from a user research project.
UX research metrics (optional). This section can detail a few different metrics, such as usability testing metrics, or something like OKRs that your team creates to track the impact of user research in your organization.
Resources. Under this section you can include any additional information that might be helpful to colleagues, such as links to an intake document, a research repository, or a research roadmap.
FAQs. This section can include common questions that you find colleagues asking you and can be a great place to send people who are asking questions about the team.
Contact for you (or the team!). Lastly, you can list all of the contact information for the team and, if you have multiple researchers, which researcher looks after what team or area of the product.
I share this information regularly with the teams I work with the most, and any time someone has a question, I direct them to this document. It becomes the go-to place for people to learn and understand how I can help them achieve their goals.
Set up a request process
I used to get research requests in all different forms:
A long-winded email
A one-sentence Slack message
Someone dropping by my desk
Everything in between
Usually, this meant I was constantly asking follow-up questions or sitting in follow-up meetings to get more information about the request. This running around took up a lot of my time and wasn't efficient. I needed a streamlined way to receive research requests and an easy way for people to request research.
I created an intake form, which I set up on Google Forms. Then, whenever anyone reached out about a research study, I sent them this intake form to fill out. Not only did this mean I received all the necessary information upfront, freeing up my time, but it also meant I only received serious requests. Once I made the document, I presented the new process to the different teams with an accompanying timeline. I circulated this form constantly around the organization, making it simple for anyone to reach out with a request. I put the link at the bottom of every summary, in every presentation, and within the framework.
Once colleagues understood the timelines and the request process, I had many more requests coming earlier, and stakeholders were much more proactive about upcoming research needs.
Create a research roadmap and backlog
After creating the intake form, I had an influx of research requests and nowhere to visualize them for myself or others. I took inspiration from the product teams and created a research roadmap, and backlog—this document listed upcoming, planned research, and research requests that we had not yet prioritized.
The research roadmap and backlog were crucial for a few different reasons:
It showed the team what research was underway, what was coming up, and when I had the capacity for upcoming studies.
The team was very well aware of when they needed to come to me to request research, changing the team’s mindsets to be more proactive than reactive.
The organization started to learn the value of user research and how I could help them through various studies.
I could show how I was impacting the organization through the work I was doing.
When I was doing too much evaluative research, it became clear and gave me the evidence to show my manager we needed to do more generative research.
When it came to performance reviews, it was easy to look back on my work, provide names of people/teams I worked with, and understand what I had accomplished.
When setting up the roadmap, I sat with my teams to ensure we aligned our roadmaps. I sat through their quarterly planning and updated my roadmap bi-weekly when I met with stakeholders to ensure everything was up-to-date. Although it was some effort, the value I got from the roadmap was incredible.
Teach and democratize, to a point
Once you feel comfortable at an organization, it is time to start looking for people who can help you, especially if you are a team of one! However, when it comes to teaching and democratizing user research, it is essential to tread mindfully.
I start with finding colleagues who have research experience or are interested in learning basic user research skills. These skills include note taking, recruitment, and non-complex usability testing. In the early stages, I bring these colleagues through a training program:
Small group classes that cover note taking, recruitment, and basic usability testing
Shadowing me for at least two studies in which we cover these skills
Conducting two practice sessions internally
Completing their first user-facing session with me shadowing
Receiving and acting on any feedback
After this training, they are free to do basic research. If those who went through training haven't researched in three months, they have to do a quick refresher of the above program, including a review class, one shadow of a study, and one dry run.
By teaching others the basics, you can free up your time to focus on more strategic and complex research, such as generative research or deliverable generation.
Invite people—better yet, create a sense of FOMO
Even if you do all the above, it doesn't guarantee that people will come running with research requests or a desire to do research. When this happened to me, I realized I had to create a sense of FOMO for the wary teams. So here are the steps I went through to get the skeptics interested and participating in research:
Find your champions. At every organization, some people are interested in (or at least lukewarm toward) user research. Grab these colleagues and get started helping them with studies
Invite relevant teams to everything. Always extend the invite to product managers, designers, and developers to come to the research sessions. Even if they say no, at least you are putting yourself out there.
Include debriefs in the research session time. Whenever I send colleagues an invitation to join a research interview, I always have the extra thirty-minute debrief in the calendar invite. For example, if the session is only one hour, I send a calendar block for an hour and a half.
Share how you are helping them achieve their goals. I get testimonials from other teams about how research has positively impacted them. After gathering a few of these, I share them with the organization to tangibly show the value user research can bring to the different teams.
Educate people on user research. There are so many misconceptions about user research, and sometimes colleagues have had bad experiences in the past. Get to know why they are not excited about working with a user researcher and point out ways to quell their fears or anxieties. For example, many people think user research has to take a long time, so prove them wrong with a lean study!
When all else fails, set up a goal for exposure hours. I was at an organization where, despite my best efforts, very few people were interested. I discussed with my manager that I would like to set up a goal for exposure hours. Ideally, each person on the product/tech teams would be exposed to customers two hours a week. When I presented this goal, I explained the benefits that come with exposure to customers. Once people started sitting in sessions, those exposure hours increased naturally on their own
Building this type of culture took time and effort. But, ultimately, developing a user-research culture doesn't only help the organization but also helps you. People will see the value you bring and, over time, it becomes easier to track your positive impact. Take the next six months and dive into creating and fostering this mindset; the work is well worth it.