We’d all love to believe that we can confidently say ‘yes’ to undertaking any UX research effort. But sometimes it simply doesn’t make sense to do so. When there are big constraints like time and resource working against you declining to do the research is sometimes the best approach. This article describes good reasons for not undergoing a UX research effort.
Reason #1: It’s too late. That ship has sailed. How many times has this happened to you: a product person approaches you about doing some research. You are eager to please and are all ears. He tells you that he’d like to do some concept testing on his product feature that is going into development in the next few days. You think, wait, what? A few days? Beginning a research endeavor at this point would be after the fact. By the time the research is completed and insights are communicated, the product will be coded!
The closer you get to the deadline for beginning development the more expensive it gets to fix any potential problems that the research may uncover. The point of the concept testing is to avoid re-coding efforts and save money. At this point, any research recommendations will depict what could’ve been done had they engaged research earlier. While the recommendations can be implemented after coding, they are going to be much more difficult to implement. Engineers will need to update their codes. Product owners will need to add new user stories. QA analysts will need to test and re-test. Every resource dedicated to making improvements is an added cost and one that could’ve been avoided by proper planning for research much earlier on in the development sprints.
Plan for research as early as possible to avoid re-development costs.
Reason #2: This really requires market research, not UX research.
If you were to ask people outside of the UX field what they thought the difference is between user research and market research, I think most would probably tell you very little or simply wouldn’t know. According to Apala Lahiri Chavan, Chief Oracle and Innovator of Human Factors International, market research is about what people will buy, while user research is about what people do and how they use products and services. Market research asks the question What are the different segments of users or prospects for a specific product? Market research attempts to understand demographics, spending habits, psychographics to better understand the market potential for a specific product. This is all in an attempt to understand what people think they will buy and what they say. While market research is like a panoramic lens on its customers, user research is more like a zoom lens, sacrificing breadth of insight in order to achieve more depth. User research attempts to understand the mental models, goals, and user needs of those specific types of users; it’s not only what users are saying but it’s also what they are doing, uncovering behaviors that can’t be easily gleaned from doing market research.
When product stakeholders come to you with questions like ‘what are the different kinds of customers that are using our products?’ Or, ‘what is their median income?’ it is more appropriate to do market research and not UX research. The UX research team might very well do some market research. We do some market research where I work in order to scale up our data collection. Product people often ask ‘how prevalent is this need or behavior?’ Market research can help us gain insight into the relative level of demand for a feature. This can help product stakeholders better prioritize their release planning of features. If your organization has a marketing department with a market research capability then they might be a better fit to do that kind of research rather than your UX research team.
Don’t be afraid to reject a research effort if it requires a method that is better suited for another department within your company or somewhere else. Stakeholders will appreciate your expertise for helping them identify the approach required and who are the right people to be involved in the effort.
Reason #3: We don’t have the resources right now to focus on the required research. It never feels good to decline a research effort. But when a team is already overloaded with projects and is forced to do more with less, it simply cannot be helped. To avoid forgetting the number of projects that couldn’t be done from a team’s collective memory, it is worth keeping track of all of those projects that could’ve been. My team aggregates our projects that didn’t get research love into a ‘Missed opportunities’ list. This list serves as not only a memorial of ‘dead work,’ but more importantly as a view into the opportunity cost of not doing research. They may represent lost cost savings or revenue gains. When strategic projects on this list are not done due to resource constraints, they can serve as evidence to senior management to increase their research resource spend; a signal to reallocate fungible resources from one part of the organization to another to help do some research.
Keep track of missed opportunities to do research. Have them in your team’s back pocket ready to show to senior management to demonstrate demand and a shortage in resources.
Reason #4: There aren’t enough questions to warrant an entire research effort. Product stakeholders may have only a couple of key questions about their product that may not require a 4 to 6 weeklong research effort. When this situation arises I look for other research efforts going on that entail similar sets of user profiles and see if there is a way to insert those questions into those efforts. This is especially useful when you are an embedded or semi-embedded researcher who has a good grasp on all of the features being worked on within your domain. As a researcher within access and identity management, I might have a few questions from my product owner about how HR administrators organize their access to their HR systems that only entails a question and answer format of 5 to 10 minutes. If I have a separate security project going on for how these same types of users want to log into their HR systems from their desktops, I can easily add these extra questions into the interview guide and add some segway dialogue into the session to make the transition from talking about managing access to discussing login methods more seamless. Think of these small sets of questions from product stakeholders as opportunities to pepper existing research efforts with more content, especially if those efforts are also lacking in content. There might be some great complementarities between the content sets.
Decline standalone research efforts that involve only a handful of questions that cannot fit into a full research effort or be squeezed into another one. Consider putting these “mini-efforts” into separate but related ones ensuring a seamless transition between the topics.
When it comes to engaging product or design teams with possible research efforts I tend to be a ‘yes man.’ Who likes a naysayer? But sometimes it pays to be a ‘No, but…’ person. When time and resource are not on your side, or, if the research ask has come too late in the process, it’s important at that time to keep stakeholders from feeling alienated or that they did something wrong. Promote transparency into your processes. Make sure that the next time they want to do research they know where in the process they need to engage UX research, and how they can help elevate their cause. Ultimately, it’s up to the UX researcher to communicate when product and design should be engaged in the process.
Source link https://uxplanet.org/4-good-reasons-to-decline-a-research-effort-6335734033b1?source=rss—-819cc2aaeee0—4