How to pitch user research if your organization seems reluctant
How to pitch user research if your organization seems reluctant
How to get buy-in for user research when budgets are tight
I recently got my organization to approve a proposal called "Future state testing," which was just basic user testing with a fancy name.
It wasn't as though they opposed doing user research, but it suddenly became a much higher priority by re-packaging it and changing how I presented its value.
Very few organizations will outright refuse to do user research, but often, it gets pushed to a very low priority. Unfortunately, in an age of tight UX budgets, this may mean that user research gets ignored entirely.
So whether you re-package it with a cool name or showcase its' value through mitigating loss, these are three ways to help persuade your team to support user research.
Here's why it can start with naming.
"User Research" can be a loaded term for some audiences
As a Junior Designer, I always insisted on using the correct terminology, which caused friction in getting research approved.
However, I've become more flexible with terminology as I've grown more experienced, especially regarding stakeholder buy-in. Whether I need to call it "Customer feedback," "Future State Testing," or a codeword like "Project Scout," I'm okay with it if it gets the team on board.
Part of the reason is that sometimes, your team may have sensitivity around calling something "User Research."
One example of this happened when I designed an application with workflows for both internal (i.e., employees at a field office) and external (i.e., customers in line) users. The "User" part of "User Research" often led to confusion because these were two different user groups.
For example, why were we immediately doing more user testing (with customers) after we had just done user testing (with employees)? Which users gave us which user insights, and how should we move forward with them?
However, this wasn't the only time the term "User Research" ran into issues.
When designing for healthcare, using "Research" usually resulted in our proposals being rejected. Why? Well, Research in Healthcare often involves clinical trials with hundreds of patients, randomized laboratory studies, or meta-analyses of existing literature to get started.
Saying that we could "research" with only five users and a short time frame caused much skepticism (to both our methods and recommendations). When most of my audience went through Medical School and often reviewed medical literature, discussing research led to more issues than not.
Lastly, sometimes you work with teams that love codenames, which may work to your advantage. If you have to get every single user testing session approved, you may be able to get blanket approval for user testing across all projects with a simple codename like "Project Scout."
It seems silly, but a simple codename can often be the difference between someone just nodding their head and seeing UX starting a remarkable new initiative.
With these ideas in mind, you may need to adapt what you call it to fit your team's needs. Here are some terms I've used in the past:
In-person Customer Feedback
Customer Input
Future State Testing
Guided tours with users
etc.
Remember, though, that this is about stakeholder buy-in: if your team incorrectly uses personas or calls technical proof-of-concepts "Prototypes," feel free to call them out. But if a simple name keeps your stakeholders from approving user research, it's better to be flexible.
However, the next step of this process is an important one where many designers make mistakes.
Persuade your team to invest in research to mitigate loss
Several months ago, I saw a LinkedIn post that changed my thoughts about persuading stakeholders about user research.
Simply put, many designers need to use the most persuasive argument for user research: to mitigate waste and loss. That's more important than ever with tight UX budgets.
When convincing their team to do user research, I've seen many designers talk about how we can understand user wants or needs to build a better product. This is a logical argument, and it makes sense, but it's not a persuasive argument.
Building a better product/feature is only sometimes at the top of everyone's list: I've learned this while working in the startup world. If user research is going to delay the launch of a product by one month, and that product revenue is keeping the lights on, it's not surprising that teams don't invest in user research.
However, discussing how user research prevents loss is often the better (and more persuasive) argument in these situations. This usually takes on one of three different approaches, depending on the stakeholders:
Minimizing burden/wasted coding time with Engineering
Mitigating timeline and budget issues for Product managers.
Reducing the Risk of wasted resources, financial costs, and time for executives."
Remember, loss aversion is a psychological phenomenon that states that losing something is twice as powerful as gaining something. For example, losing $10 hurts twice as much as you would feel happy from gaining $10.
Talking about how user research can help avoid losses (or mitigate them) instead of talking about the gains teams will get from it is often a critical step toward stakeholder buy-in.
Each of these arguments also shifts the conversation from a future-facing argument (i.e., the product will be better in the future) to a present-facing one (i.e., We'll avoid wasting resources if we need to redesign or scrap a feature).
Doing so also allows more budget-minded team members, like Product Managers, to see why User Research is essential to budget into their process.
Lastly, talking about the Why is another crucial part of creating a better pitch for user research.
Align your "Why" with your businesses' main questions
You're doing user research for one reason: you have some unanswered questions about the user, their needs, workflow, or your design, and you want answers.
Businesses also have unanswered questions, although they're around customers, product-market fit, and more. Aligning the "Why" of both user and business questions can be critical to getting your business to accept the fundamental reasons behind doing User Research.
For example, imagine that your business mainly cares about getting repeat users (i.e., people who log into their product a 2nd/3rd/4th time). In that case, your Why might involve understanding your user's typical workflow or routine and what causes them to log back into an application.
You would want to have your users test your website, of course, but you would also want to ask questions about what features they might use frequently or what would cause them to return to this site.
If you can show that the "Whys" for User research are aligned clearly with what the business wants to learn, your organization will be more likely to support your efforts to implement user research.
Do whatever you can to ensure user research gets done
Right now, we're in a time of tight user research (and design) budgets. In these scenarios, it always seems likeuser testing is one of those things that fall to the wayside, and if you present it as a "future-facing initiative," it might be.
However, we know that user research is a critical part of building a better product and that investing a little in user research avoids needing additional budgets and timeframes to redesign failed products.
We may need to change how we pitch user research and the value it brings to stakeholders to get them to accept it.
By emphasizing the core reasons for user research, helping organizations avoid losing resources, and being flexible enough to adapt the name, we can often get the buy-in needed to make it work.
Doing that, rather than emphasizing the 'proper name' and exact processes you learned in school, can be the critical part of whether your organization supports user research or pushes it to later.
So, if you've ever had your pleas for user research fall on deaf ears, consider these three tips to help pitch it to your stakeholders. Doing so may get you the approval that you desire.
Kai Wong is a Senior Product Designer and Data and Design newsletter writer. His book, Data-Informed UX Design, provides 21 small changes you can make to your design process to leverage the power of data and design.