How to make the case for user research in the face of adversity
Have you ever been in a situation where the deadline is fast approaching, there's still a huge amount of work to do, and something needed to be cut to get it over the line? I'm pretty confident in saying that anyone who has worked in a large organisation will have been in this situation. What was the first thing to be culled from your process? My guess (albeit an educated one from years of encountering this very situation) would be user research.
To make the case for cutting user research to pull in those tight timelines to aim for a predefined delivery date, you'll hear things like "we already know what our users want", or "it's too hard to find the right people in such a small amount of time". There are many more, but you can read about those in the article titled "The most common excuses for not doing user research" from the UX Collective.
It's hard to argue against these excuses in this kind of situation. Or is it?
Many times we find ourselves in a situation where we - as user-centred designers - believe the right course of action is to follow the process through to ensure we are building the right thing for the right people, but this can be viewed as a juxtaposition to those stakeholders who may be more business-focused and intent on delivering what has been promised.
So how do we overcome this impasse where these different viewpoints clash?
Meet them where they are
To communicate effectively and push our agenda of a user-centred approach, we must speak in terms that are more easily understood by the business-driven stakeholder.
People in business follow the numbers.
If you can display the value of a particular approach in how it will 'move the needle' towards the business goals, then you are halfway to convincing them that your approach is viable. However, the real value comes from your ability as a designer to mitigate risk.
Nobody who is driven by business needs in this way likes to invite risk. Anything that helps to make the outcome more certain is a welcome addition. It helps to set more achievable targets and helps to avoid numerous possible roadblocks as a project moves forward.
Ask your stakeholder; Do you want us to spend time on designing this new idea that has been handed down to us, or would you prefer evidence-driven decision making? Do you want us to prove that we're doing the right thing for our users and our stakeholders?
If they don't want increased risk in their project, it becomes a no-brainer. They know what they have to invest in research to obtain that evidence.
Take them where they want to go
As a User Experience Designer or Researcher, you have to provide the evidence to the stakeholders that utilising research as part of the process is a step that should never be skipped. Whether your results reveal that we are about to build something that none of our users would ever use, that it would be the best feature to be made available to them, or anywhere in between, we now have evidence as to what our next course of action should be, whereas previously we were essentially flying blind and trusting our ideas to deliver what the users need.
If we are building something that will be used by anybody outside of our organisation, then it is safe to say we are not our users. The only way we can understand what our users need and want is to find out from them.
Do the stakeholders want to trust designers to design a solution to a problem based purely on their experience and/or intuition? Or do you want to know that we are not only building the right solution for their problem but that we're solving the right problem in the first place?
For the cost of a small dent in the budget, and the minimal time needed to test with a handful of participants, you can gather enough evidence to prove what your doing is taking you down the right or wrong path.
A couple of days in terms of cost to a deadline when compared to weeks or even months of development and testing time easily tips the scales in favour to know which direction you should be going before you take those first steps on a path.
If you want to build the right thing to solve the right problems for the right people, and you need to mitigate the risk of your project, the answer is to do your research.
Let me know how it works out for you
Have you had problems with research being cut from your project due to timelines, budgets or other constraints? What did you do to make sure you did the right thing for your users and your business?