How to partner with UX researchers to positively impact product and business

Tatiana Vlahovic
UX Collective
Published in
10 min readJan 31, 2020

--

Image from shuttertstock

Your product team wants to be more user-centered. You hired your first UX researcher (or you’re looking for one now!), and you’re excited to work with them. Or, you may have a UX research team in your organization, but you’ve never worked with them. Either way, research is new territory. You don’t know what problems UX research can help you solve nor how to work with research.

In this post, I will explain what UX research does for organizations and how to best partner with researchers. I wrote this for people in design, product, engineering, and business development roles who wish to collaborate with research; however, it could equally help a UX researcher explain what they do to their new teams!

What do UX researchers do for an organization?

A UX researcher empowers organizations to deeply understand people who currently and who might use the product so organizations make decisions that benefit both users and the business. UX research investigates people’s experience at 3 levels described by Kim Flaherty: the interaction, the journey, and relationship to the organization. A researcher is a “compass throughout the product development lifecycle” (see Steve Wengrovitz’s post) and a “multiplier” that creates ways for the whole organization to learn about users (see Monty Hammontree’s post).

Research isn’t limited to usability testing an interface; it’s a powerful tool to guide product design and business strategy.

Insights from UX research typically have the biggest impact on short-term and long-term product development, but can have implications for all parts of the business. Research addresses both foundational questions (e.g, How do we position our product for adoption by the early majority?) and tactical questions (e.g., Why do people drop off toward the end of the purchase flow?).

Broadly, research guides product development in the following ways:

  • Research before product development helps you build the right product.
  • Research during product development helps you build a product in the right direction.
  • Research after product development helps your know how successful your product is, and where it needs improvement.

I provide examples below of potential questions, how research might answer these questions, and the impact research can have on product and business.

Your team might ask the following foundational question: What product offerings should we release 3 years from now?

  • UX research can address this amorphous question by investigating the lives of people you’re interested in — what does their day-to-day work look like outside of your product? Methods might include in-depth interviews (in the lab or in people’s homes/workplaces), diary studies, surveys, and competitive analysis. Research would also triangulate data from multiple sources (e.g., existing research, analytics, data from customer-facing teams like sales, support, and marketing). Based on this data, research would identify opportunity areas and use cases based on people’s needs, motivations, and behaviors. This knowledge positions your business to build the right offerings 3 years into the future.

Your team might ask the following tactical question: Which design prototype (out of multiple options) best supports people’s workflows?

  • UX research can address this question by better understanding the context in which people use your product, whether the prototypes solve their problems and help them achieve their goals, and how well or not well people can perform key tasks with the prototype. Methods might include concept/prototype testing and usability testing. Based on this data, research would help you quickly evaluate designs with prototypes before they’re given to engineers to build.

What methods do UX researchers use?

UX researchers conduct both qualitative and quantitative research, but their methods tend to be more qualitative because the goal of UX research is to understand people’s experiences and behaviors in depth. However, there are quantitative UX researchers who specialize in statistical analysis of survey and behavioral log data (see post by Duyen Mary Nguyen, Saide Bakshi, and Alex Whitworth).

Qualitative research answers “why?” and “how?” questions to understand people’s attitudes, motivations, and processes. Qualitative research often involves interviewing and observing smaller sample sizes of people to answer descriptive questions. Examples of questions that qualitative research could answer are:

  • Why are people dropping off in the purchase flow after adding items to their shopping cart?
  • Why do people shop for a product online instead of a physical store?
  • How do people shop for a product or service online?
  • How do people feel when they’re shown ads in one context versus another?

Quantitative UX research answers “what?” and “how much?” questions to investigate behaviors and attitudes across large groups of people. Quantitative research often involves performing statistical analysis on survey data and behavioral log data with large samples of people to answer experience questions of scale. Examples of questions that quantitative research can answer are:

  • How many people recall seeing a targeted ad on the website?
  • How satisfied or dissatisfied were people with the ad?
  • Were people in Condition A more/less frustrated than people in Condition B? Is that difference statistically significant?

For a comprehensive review of qualitative and quantitative research methods and when to use them, check out this article by Christian Rohrer.

Who do UX researchers work with?

A UX researcher typically works with product teams consisting of different skills that push forward short-term and long-term product development: design, product management, engineering, and content strategy. In some organizations, non-researchers conduct user research themselves — and that’s great after receiving training on research methods and best practices! It’s important to remember that while a researcher can train non-research partners in research basics, research is still an expertise that takes years of practice to do well and yield confident results.

A UX researcher will also work with other teams like sales, marketing, customer support, and analytics to consolidate existing internal knowledge. These teams have a wealth of information to share, which means researchers will not need to start from scratch when beginning a new research project. Findings from research are also important outside of product. For example, research insights can have implications for the sales funnel, how marketing positions a new product launch, help articles, and customer support training.

How do I effectively collaborate with UX researchers?

(1) Work with your researcher to identify “people problems” that your product can solve.

For products to be successful, they need to solve a need that people have and have clear use cases. If the product, service, or technology offering does not fit into people’s lives, it will not be successful in the market.

J.T. Trollman explains in his post, “‘People problems’ […] are needs and issues as they might be articulated by people on the street. They identify progress that people are trying to make in their daily lives and define what’s broken or unsatisfying about their current solutions. Note the difference between these and company problems — which are internal goals, priorities, and challenges that map back to your company mission.” To understand people’s needs, we must first identify the people problems (e.g., “My family has outgrown our home, but most bigger homes in our area are now outside our budget.”) and distinguish these from company problems (e.g., “We need to grow product adoption by 5% this quarter.”).

UX research is an excellent tool for identifying people problems; however, product teams sometimes shy away from research because they’re under pressure to quickly develop a minimum viable product (MVP) to meet an organizational objective. Unfortunately, this can lead to the trap of creating the wrong technology first and then puzzling over how to get people to use it, leading to lots of waste.

Research doesn’t have to slow you down, especially if you follow Steve Wengrovitz’s tips to get your researcher involved early, communicate your short-term and long-term research needs, and ask your researchers questions instead of asking for research methods. Your researcher will work with you to determine what research needs to be done, how research will fit into the product development roadmap, and what research methods are appropriate.

(2) Show your researcher what the organization already knows about its users and non-users.

Research doesn’t have to start from scratch! Often organizations have existing knowledge from sales, customer support, customer service/success, analytics, marketing, etc. (see my LinkedIn post and others’ comments on this topic). A researcher will use this knowledge as a starting point for their work and also figure out ways to incorporate this information into product development.

(3) Communicate what decisions research will inform and the priority level and timelines for those decisions.

This will enable your researcher make a more targeted research plan and prioritize the project based on impact and urgency. You want your researcher to spend time tackling the most impactful questions. What research insights would yield the most return on investment for the product or business? If you’ve already made decisions you’re reasonably confident about, and findings from research wouldn’t change plans, then you don’t need user research. When you conduct research as a checklist item in product development, this takes away from research with a higher return on investment. There are also times where it’s not appropriate to do user research, such as when behavioral analytics are better suited to answer the question or when you don’t know what you’ll do with the research (see Michele Ronsen’s Awkward Silences interview and LinkedIn post).

(4) Get involved in the research process, give your researcher feedback on the research process, and be ready to do some research yourself!

Will Myddelton aptly describes user research as a “team sport.” A researcher will not disappear and then give you a big reveal moment when the research is complete. Your researcher will likely want to involve you in some or all of the following steps: research planning, data collection, data analysis, and sharing of research more broadly. Being involved in research enables you to see what your users say and experience first hand, without waiting for your researcher to tell you later in a share-out. It also enables you to give your researcher feedback along the way to learn what is important (e.g., if you want them to spend more time on a specific topic with participants).

Ways to collaborate with your researcher during a research project:

  • Work together on defining project goals and focus areas.
  • Give your researcher feedback on study materials (e.g, discussion guides, survey drafts).
  • If your researcher needs prototypes or builds from you to do the research, align on timelines so that your researcher has sufficient time to pilot those and incorporate them into the discussion guide. (See Michele Ronsen’s post on the importance of piloting research.)
  • Attend research sessions, take notes, and comment on what stands out to you (in your notes, over Slack, etc.). If your researcher is okay with it, ask participants interview questions directly!
  • If you attend a research session, debrief with your researcher about what stood out to you as the most important moments and why.
  • Participate in research synthesis sessions.
  • Discuss with your researcher what implications the findings have for your product, service, or wider business.
  • Give your researcher direct feedback about the research process. What is working well and what are development areas? What is YOUR user experience of how your researcher brings you into the research and how they communicate findings? This feedback will help your researcher to work more effectively with your team.

You may encounter a situation where you’ll need to take on the research yourself, which is an amazing opportunity! As Monty Hammontree explains, the role of research is “empowering everyone to learn.” Your researcher is an expert on research, not a research gatekeeper. To that end, your researcher may offer consulting on research projects you take on, train non-research partners on research methods and best practices, and develop self-service resources (see Reduct.Video post by myself and Prabhas Pokharel about some ways researchers have democratized research in their organizations).

(5) Involve your researcher in non-research activities.

While researchers specialize in research, our facilitation skills and strategic mindset can impact our organizations in more ways than conducting new research projects. Here are some ways that researchers have partnered with teams in their organizations. These are based on responses to my LinkedIn post, as well as my past observations and conversations.

  • Workshops, sprints, and brainstorms for product roadmapping and generating design/product ideas
  • Activities to identify trust-breaking / trust-building moments for users, understand users across their lifecycle, and align multiple teams on how to teach users new interactions
  • Synthesis of existing research, both internal and external to the organization (sometimes new research is not needed because past research exists!)
  • Trainings and workshops on research methods (e.g., interviewing users), sketching, journey mapping, and empathy mapping
  • Consulting on research projects that non-research partners conduct themselves (e.g., weekly research office hours) or on client research strategy
  • Consulting on design strategy and on quarterly/annual product roadmaps
  • Retrospectives on team collaboration
  • New employee onboarding and orientation (e.g., vision exercise board game, bringing research insights into orientation activities)
  • Document and share product feedback from sales and customer service
  • Setting up tracking systems to measure sentiment and behaviors
  • Selecting markets for testing products prior to wider release

(6) Work with your researcher to set the foundation to scale research in your organization (e.g., participant incentives, software/tooling, research ops).

I’ve had team members new to research express discomfort with paying research participants due to concerns about introducing bias. Michele Ronsen explains while it’s not possible to entirely eliminate bias, providing participants with an incentive for their time does not introduce bias if a researcher does their job properly: “We might be testing a hypothesis, a prototype or something else entirely, but we’re never testing ‘them’” (post, webinar). Giving research participants an incentive for their time is standard practice across industry and academic research. If budget is constrained and monetary payments or gift cards aren’t an option, then consider providing participants with discounts / credits for your products, swag, or entry into a raffle. Either way, it’s important to show appreciation for their time sharing their experience with your team.

To scale and conduct some forms of research, your researcher will need software and tools. As your team of researchers grows, they’ll need Research Operations to do research more effectively at scale (see Re+Ops community). The research SaaS products your researcher brings in will depend on your organization’s needs, budget, and the type of research being done most frequently. Check out the 2019 UX Research Tools Map by UserInterviews to get a sense of what is out there! If budget is tight, there are always creative workarounds (e.g., see my article about using Google Docs as a tool for different kinds of remote research).

Thank you to Amy Santee, Michele Ronsen, and michael / nagle for reviewing and providing feedback on drafts of this post.

The beliefs and statements included in this article are my own opinions, and do not necessarily reflect those of my current nor prior employers.

--

--