That feeling of giving your client that first experience with research can be unique. That moment when they cannot precisely pinpoint who their users are and what they want, that moment of clarity you can bring through your work. That’s the ideal scenario.
The truth is, this happy path is only possible if there is an effort from both sides. You don’t have people’s trust by default. Working in a tech company or a start-up is no different from working in another profession; You are put together in the same room with multiple people with various roles, but working together towards the same goal. Building this trust is going to be ongoing work. This is not a walk in the park, but you can improve the process by taking care of some best practices. Below I am sharing the ones that I tried and tested.
Show them, don’t tell them
Although we say that the view on UX and research has changed in the past few years, many people still need to understand research’s value fully. UX research rarely tells stakeholders what they want to hear, and it usually comes with many proposed trade-offs, some of which might come as a shocker or end up ignored. It’s our job to make this easier to understand and explain their value.
If you’re working with stakeholders that don’t believe there is no problem to be solved, exposing them to these problems can have a lot of impact. And with everything in Design, visual material can have more impact than presenting the findings at the end of the process. If you summarize your insights into a written report, try including bits of user interviews. Or show them how the product is being used. Making the user real is a way of removing the bias and assumptions that go along with this.
The more you involve your stakeholders in your research, the more they connect with your work and results, leading to less friction and more trust.
The worst-case scenario
Speaking of friction, there are various levels of push-back or distrust that a researcher can receive. Whenever I need to face them or don’t manage to remain in the problem space, I turn towards showing the worst-case scenario. In other words, I show people the risk of not doing what they don’t want to do. What happens if we make an assumption about a group of users and that assumption proves invalid? What is the impact that this has? Is this a minor feature, or could we significantly impact the product’s core?
If an alignment session via Zoom won’t cut it, and if you have more time on your hands, another tool that proved to be valuable is called assumptions slam. This is an exercise in which assumptions are documented, discussed, and prioritized. You have a two-by-two grid with two dimensions: riskiness and knowledge.
There is a quadrant called high risk and low knowledge, where the research focus should go first. I won’t dwell too much on the details here, but if properly conducted, this activity can provide more clarity to stakeholders by generating good conversations about the best way to move forward.
Create a support network
When working on a project, we often need to remember that the ultimate goal is to coexist harmoniously with various roles and create something together. Each team member, including stakeholders, brings something to the table. The secret to maximizing the impact of your research and creating the so-much-needed support network lies in maintaining this relationship rather than preaching your idea to another person with different values. The correct approach is to challenge each other with your way of thinking and bring another perspective to the table (the users’ perspective). These should lead to fruitful discussions and making decisions, considering multiple perspectives.
Try creating a support network in the organization you are working on. The closes person is the Product Manager, so keep him close. If there are other Designers, it’s also essential to involve them. Refrain from guarding your findings. The more you include others in the process, the more insights you can find and extract, simply because everyone brings something new and unique to the table.
Keep them in the problem space
People still talk about focus groups when they hear about research, but research is broader than that. Or they think about A/B testing or surveys.
People tend to employ the method they are familiar with to find answers immediately. It’s human nature. When people recognize that they have a problem, they want to find a solution as quickly as possible. They look for a quick way to make decisions without considering the whole context.
So before caving in and doing research just for the sake of doing it, make sure you map out all the questions or assumptions you have and devise a plan. Try to think about what you don’t know and what you would like to find out, all while staying in the problem space. Don’t let yourself focus on shiny features just yet; there will be time for that as well.
I think it was Erika Hall who summarized it pretty well: Who cares what the solution is if you set up your shop in the wrong problem space? It’s the solution to the wrong problem.
Set boundaries and align on time needed
When doing UX research, we have a set of methods; some are quick, and some are more elaborate. Naturally, companies are sometimes in a hurry to find answers and get their product out the door. In this context, aligning expectations and the time needed to conduct your research is crucial. At the beginning of the collaboration, try to be as transparent as possible about the time required to conduct research. Block time in your calendar, and offer regular updates on the process and what you plan to do next. It will show people you know what you are doing, and at the same time, it helps them become aware of your boundaries.
In addition, saying no is one of the most important things to learn. Make the research visible across the company, and if you think something should be (de/re)prioritized, speak up. Keep close to your support network we talked about earlier, and discuss any conflicting priorities.
Improve your communication
When you sit down to Design stuff, the right approach may seem obvious, and communicating why it’s right is a different animal altogether.
To help with this, you can rely on business language, the user’s point of view, and the outcomes and impact (no matter how small) your findings can have. To account for the business side, you can think about revenue, cost, risk, or retention. To account for the user’s point of view, express their needs, problems, or friction points. Finally, when talking about the outcomes, elaborate on how a design decision can change the current state of the product and business.
Let’s take a look at an example of a simple upload flow:
“Based on recent tests, users need clarification when returning and help to find where to upload documents. This Design makes the upload button much easier to find. Making uploads easier means more accounts being set up, and this version should convert better than our current implementation.”
We went through a lot of information. Let’s do a quick recap of some of the best practices to get your research to the next level:
- Never do your work in your corner. Bring your stakeholders along as you are doing your research. Doing this helps amplify the impact of the research.
- When dealing with a lot of push-back or distrust, make people aware of the risks involved in operating under assumptions only.
- Create a support network within your company, and ensure you align on what’s a research priority and what is not.
- Stay in the problem space as much as possible, no matter how tempting it is to jump into solutions. You don’t want your product to be a carnival of features that nobody wants.
- When communicating with stakeholders, think about the business impact and the outcomes of your research.