How to handle objections to conducting User Research
Ever experienced pushback to conducting user research to inform product or service changes? Try these tactics to handle objections, whilst staying friends with your coworkers
When you are passionate about User Experience (UX), it can feel like a serious affront to both your profession and convictions when the need for user research is flatly dismissed by colleagues. In my experience working in the UX Research space for best part of a decade, the objections generally fall into three main categories:
- Concern for the time required to include research in a development cycle
- Conflating customer feedback with user research
- Assuming that user needs are already well known and understood
It’s hard to push back on these objections. We like our colleagues (right!?), we want to work harmoniously and add the maximum amount of value possible, advocating for what we feel is right for the user and the business. So here are some ideas about how to respond to common objections, whilst staying in everyone’s good books.
It takes too long, we just don’t have time!
The passive aggressive response to this would be, “Ok, well how much time do you have for reworking the design that completely misses the mark for the user?” (I haven’t.. not said this once or twice…) but the more constructive thing is to look at the source of this person’s perspective.
Either user research have been engaged too late in the process to have a meaningful impact (it happens) or the folks you are working with genuinely don’t see or plan for research in the development cycle as a matter of course. Both of these objections come back to education; what research is, how it adds value, ultimately saves time and money and mitigates risk to your business.
Reminder too, that research is not always all or nothing. Think about the overarching objectives for a proposed product change and what you can do in a lean way within the time and constraints you have. Perhaps an unmoderated usability study or survey? Some desk research or data mining for previous research or user feedback on the topic? Worst case scenario, you can help to structure a great post-release feedback loop or some product analytic tracking to monitor how it’s being used and received, and identify if you need to iterate on your original design. Longer term, it’s really helpful to educate your stakeholders about the research process, the right time and way to engage you, and some examples of potential timelines so they can better anticipate and plan for your involvement.
A bonus tactic for helping your team to understand the value of research is if you can point to any prior feature or product releases that did not involve research, and what the business and user impacts were. If you don’t want to offend anyone, you could try and cite some examples from other organisations.
Bottom line: We can’t assume the folks we are working with have a perfect understanding of the function, purpose and practicalities of user research. It’s up to us, and actually a big part of our job as researchers to guide and educate them.
But we already have customer feedback, like the NPS!
I am actually a big fan of utilising customer or user feedback from preexisting channels wherever and whenever possible. Oftentimes, these will point to genuine pain points your customers are experiencing. Let’s use an analogy of a treasure map; X (the customer feedback) marks the spot, but user research is both the shovel and the act of digging to see what you can find below. Customer feedback like NPS can be a start, and a great source for data triangulation, but usually it isn’t enough on it’s own to design a user-centred solution to the identified problem.
Imagine you are an online bank and measure a customer satisfaction metric. You notice you are getting a lot of feedback relating to customers being dissatisfied with the money transfer function. OK, so there’s a problem, that much is clear, but how do you know how to solve it? You may get some customers leaving thoughtful and detailed feedback about the context, impact and potential solution to their problem, but more often than not you may just get a quantitative score or ‘worst service ever what a piece of ^&*#!!!!!!’ type rants at best. Which are, errr, helpful in understanding the gravity of dissatisfaction, but not so much to design solutions and create a more valuable product. User research helps to dig deeper into the problem space, enable solution ideation and validation that you are on the right track.
Bottom line: Customer feedback is helpful and serves an important purpose in identifying high level customer issues and pains, but is most likely to be inadequate on it’s own for product or UX design purposes.
We already know what the user wants, and we are the user too!
Again, this objection is not inherently bad and there is usually a kernel or more of truth in this, particularly if it’s coming from a user-facing colleague. BUT… an objection like this is usually based deeply in (maybe unconscious) bias, which is what we naturally try to avoid in making design decisions.
I would respond to this by asking a few key questions:
- Great! Can I ask where are all the user needs are documented and even better, prioritised?
- Are all our users the same and have the same needs? If not, what user groups and use cases do we need to consider? Could you show me where I can find them please?
- Do you think that our intimate knowledge of the product would be the same as an average user? What do you think might seem a bit different for their experience as a user vs those of us who work for this organisation?
If a team mate can confidently address all questions, then colour me shocked and yes you may have already had a lot of the hard work done for you, at least in understanding existing problem spaces.
In the more likely event that their response is a bit more ¯\_(ツ)_/¯ in vibe, then that is the opportunity to explain that as a user researcher, you can help. Remember, there may be some existing knowledge within your organisation, and you can always use leaner methods like stakeholder interviews, feedback reviews or whatever sources you can get your hands on to start with before launching another study
Bottom Line: It’s very likely that some internal knowledge exists in your organisation, and there is absolutely nothing wrong with using this to familiarise yourself with a topic. In fact, it can help to reduce the scope of any subsequent research study to focus on the biggest unknowns. But a reminder also, that ‘knowing what the user wants’ doesn’t always help us to know their behaviours, goals and motivations behind what they want, which are inherent requirements to great design.
To sum up
It’s entirely normal for folks who are unfamiliar with user research to challenge the need for it. As hard as it can be to handle these objections, it helps to remember that you are, quite literally, on the same team and probably ultimately share similar goals. I hope these suggestions help you on your way to demonstrating the value of user research, and making better design decisions.
