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.