Table of Contents Hide
- Fallacy #2: UX research is all about talking with users.
- Fallacy #3: A UX research project ends after completing the research.
- Fallacy #4: Stakeholders drive requests for UX research.
- Fallacy #5: UX research is about conducting one study after another.
- Fallacy #6: UX research is all about collecting user feedback.
- Fallacy #7: UX research is all about working with your product team.
Fallacy #2: UX research is all about talking with users.
You can conduct research in a variety of ways, including by talking with users, learning about their attitudes, measuring their behaviors, and collecting their psychometric data. However, UX researchers spend a large portion of their time doing things other than collecting data, such as socializing their research methods, processes, data, and insights with their team.
Cultivating cross-functional relationships with stakeholders is the most important part of the UX researcher’s role. As a UX researcher, you may be collaborating with other UX researchers, designers, product managers, content designers, marketers, and business leadership. Many of these people might never have had any exposure to UX researchers before, making it imperative that you cultivate trust and build partnerships with them.
UX research is not a solo activity. It typically involves working with collaborators at every stage of a project. While UX researchers uncover insights, they seldom have the agency to implement them. Stakeholders such as product managers and UX designers typically make such decisions. Cultivating relationships and establishing credibility and trust with these collaborators are essential if UX researchers hope to make an impact by having their research implemented.
Fallacy #3: A UX research project ends after completing the research.
In an applied-research setting, just doing a research project is not enough. You need to evangelize your insights with stakeholders. Once your research concludes, the longer process of converting your findings into actions begins. Figure 1 shows the process of turning your findings into actions.
After collecting your data from a research project, inducting your stakeholders into your research findings could involve several steps, as follows:
- Synthesizing your data—Involving your stakeholders in research activities such as user interviews, notetaking, and synthesizing your findings and insights is always good practice. To help stakeholders better empathize with your findings, conduct an insights workshop during which stakeholders can debrief you on your observations, collaboratively come up with themes from your findings, and collate everyone’s notes from your workshops.
- Presenting your emerging insights—Present your insights to core stakeholders, who are directly involved in the project, and ask them to provide feedback. Use their feedback to refine your themes. You can present insights in the form of How might we? questions. For example, “Users don’t understand how to do an image search on the Web site. How might we better enable users to use the Web site’s image-search feature?”
- Brainstorming insights and actions—Ideate solutions for the painpoints that you’ve identified. Once you’ve identified research insights and How might we? questions and presented them to stakeholders, consider what might be some potential ways of solving these problems? You might start by brainstorming potential solutions, then vote on which of the proposed solutions might be most feasible and impactful once implemented.
- Determining timelines—Once you’ve identified solutions for users’ problems, prioritize their implementation on your product roadmap. Answer these questions: Which solutions should you implement immediately? Which should you table? Reiterate your insights and solutions and ensure that they make it onto the product roadmap.
- Doing an extended readout—Once your team is in agreement regarding insights, problems, solutions, and their implementation, present your research findings to an extended group of stakeholders—perhaps including Sales and Marketing. Do this presentation collaboratively, asking each of your core stakeholders to share their part in the journey.
Fallacy #4: Stakeholders drive requests for UX research.
UX research requests can have different origins, as follows:
- top-down requests—A stakeholder, C-level leader, or manager requests that UX researchers conduct research in a particular area.
- bottom-up requests—UX researchers have the autonomy to propose their own UX research projects, but stakeholders must sign off before researchers conduct the research. This approach is more common for UX researchers working on a product team than in an agency. Rather than focusing just on what research your product space requires, you can propose research that is based on business goals, objectives, and users’ problems.
In most organizations, the ratio of researchers versus designers, product managers, and engineers is skewed. This usually results in UX researchers fielding many more research requests than they can fulfill. Therefore, it is important for UX researchers to develop a process for vetting research requests and choosing the projects that would be most impactful.
Fallacy #5: UX research is about conducting one study after another.
If you are working as a UX researcher in a specific domain, or product space, it is likely that you’ll build domain knowledge over time. Your learnings could include deep knowledge of relevant user personas and their journeys, painpoints, and product and process expertise. Plus, as you gain experience as a researcher, it is important that you revisit your past research to look for any insights you might have missed.
UX research is about looking for patterns in your data. You’ll do this for each individual study that you conduct and, over time, you should assess your data across studies as well. If you have a social-sciences background, you may have come across the term meta-analysis, which is the process of looking across individual studies to observe effects and patterns. Combining findings from multiple studies from the past can help you to do the following:
- Identify missed opportunities to turn insights to action.
- Observe changes in personas’ attitudes, behaviors, and characteristics over time.
- Propose research in areas that remain unexplored or that answer questions that you’ve left unanswered during your previous research.
- Level-up your skills as a UX researcher so you can advance up the career ladder.
Fallacy #6: UX research is all about collecting user feedback.
When planning a UX research project with users, you need to think about the right UX research methods to employ, numbers of participants, and recruitment strategies. However, in some cases, you might already have the answers within your existing information. Secondary research refers to summarizing, collating, and synthesizing existing information. It is a powerful technique that is often underutilized, can save you time and resources when you’re establishing the context for your next study, and prevent your reinventing the wheel.
Remember to harness the power of secondary-research sources such as the following:
- findings from prior research in your product domain
- research reports and presentations from other UX researchers within your company
- findings from research that cross-functional teams have conducted—such as your Product or Design team’s competitive assessments or your Design team’s usability studies
- industry- and market-research reports—for example, those from Pew Research Center, Gartner, or Forrester Research
- scholarly articles or papers from many sources such as Google Scholar or ACM (Association for Computing Machinery) publications such as ACM Transactions
- Internet searches
- artificial intelligence (AI) tools
Fallacy #7: UX research is all about working with your product team.
Different organizations have different structures. If you are part of an organization that has a mid-sized or large UX team, comprising more than 20 people and including researchers, designers, content strategists, and operations, you might benefit from being part of that larger team as much or more than from being a part of a product team. As part of a UX organization, you can participate in building culture, sharing knowledge, and providing peer support. Some examples of UX team activities include the following:
- curating talks for team development
- developing the team’s best practices
- elevating the team’s expertise in various methods
- organizing team-building activities
- organizing internal conferences and conventions
- sharing knowledge through lunch-and-learn presentations
- participating in industry conferences
- engaging in external communications such as by writing thought pieces
Read the full article here