How to make your user research matter
UX research can feel like an impossible job sometimes. We spend countless hours coming up with discussion guides, seeking out and then patiently listening to users’ tales of woe, poring over mountains of data to find the answers… and then distil it all into a digestible format that makes it look impossibly simple to the people consuming it.
We reach the end of a study, present it to our stakeholders and feel a sense of accomplishment as they nod emphatically and thank you for opening their eyes to such an important issue.
And then we wait. And yet nothing really happens.
If this is a scenario that you’re familiar with, then you may benefit from these techniques I’ve compiled that will make your research matter to your colleagues. I mean really matter — in a way that cuts beyond the platitudes and actualises change.
Research question generation
In companies with high UX maturity, foundational (or discovery) research is readily understood, valued, and conducted when required. Unfortunately, in most of the companies I’ve worked at, this has never been the case.
So when the opportunity arose to start a new project in my team at FanDuel, I pounced on the chance to do some ‘proper’ foundational research. Only I didn’t even know where to start. I didn’t know what I didn’t know.
The stakes were high. I needed to show everyone how valuable foundational research was so I’d get the opportunity to do it again and again. How could I make sure the findings would make everyone sit up straight in their seat and listen this time?
I realised that the answer was simple. I could simply ask everyone what they care about (in the context of our project, that is).
I invited every stakeholder involved in the project to a workshop — all the way up to the most senior decision-maker. This was a daunting prospect, as up until then I’d squished my playbacks into as little time as I could, often piggybacking onto existing meetings to make the research as palatable as possible for the people who needed to hear it.
However, if you don’t send a message that the work you do is important and demands your colleagues’ time and attention, how can you expect them to see it as little more than just ‘food for thought’?
The workshop format itself was simple. I set a timer for five minutes and asked everyone to generate as many questions as they could about a specific broad topic. I talked them through what makes a good research question (open questions beginning with ‘how…’, ‘what…’ etc. rather than ‘can…’ or ‘do…’).
I was pleasantly surprised by how many questions the team came up with! There were lots to go through. We grouped them into themes, removed duplicates, and then I asked each person to talk through the questions they’d written.
We added additional questions to the board that came up during the discussions, then we individually dot voted on the ones we wanted to answer the most.
This list of questions then became my prioritised list of research objectives. I was able to draw up a research plan that everyone was fully invested in because they helped create it!
Collaborative research insights
Planning is only the first hurdle. I then had to conduct the research and analyse the findings.
I decided to go through my usual process of affinity mapping the user quotes, creating video supercuts of the key moments from the sessions and compiling the research insights.
However, instead of presenting these back to my team as I usually would, I decided on a different approach.
I played each video supercut to the team, showed them lists of grouped user quotes, and asked everyone to write down what they thought the insight was. Everyone presented their insight back to the team and explained how they came up with it. At the end, I revealed what my original insight had been, and we finalised it together.
This concept may sound risky to some researchers. It’s a bit like research-by-community. Admittedly, it’s not going to work in every situation. It requires a team who have had plenty of exposure to research playbacks, presented by actual researchers such as yourself, and who trust you and value what you do. It requires you to maintain control over the session and be the deciding vote when any disagreements occur.
But the value of facilitating a session like this is that people are more likely to remember the research beyond the playback. It stops your playback from being an opportunity for a nice open-eyed afternoon doze, a welcome break from all the emails and lines of code, and turns it into a team activity that actually moves people to action.
Persona improv
If you manage to achieve full engagement in the planning and actioning of user research, then kudos to you! That’s an achievement. The next step is helping them to actually embody the users and truly ‘empathise’ with them.
This idea started as a far-fetched idea during lockdown that ended up becoming one of the most fulfilling things I’ve done in my career!
I had done lots of foundational research at this point and had decided upon personas as the primary communication tool, to sum up our users’ differences in motivations and habits.
Instead of presenting these personas, I pulled all the stakeholders in for another workshop. Again, this included the most senior decision-makers on the project. This time the stakes were even higher because this was to be far from a typical business meeting.
I began by splitting everyone into small groups, ensuring that each group contained at least one person who was a user research advocate and could keep the activities going (such as a product designer or UX writer or content designer). Each person within the group was given a different persona and the corresponding user journeys. I gave everyone some time to become acquainted with their persona — roughly ten minutes.
I then assigned each member of the group a different role: one was the interviewer, one was the note-taker, and one was the user, acting as their persona. The group would take turns interviewing each other like a real user interview until they’d learned a bit about each of the different personas.
Then, I gave each group a different mocked up flow of a new feature that the designers and I had created and asked them to “walk through” the flow while staying in character, speaking up for their persona where they felt that something was missing or frustrating. They added post-it notes to the flow that described any issues they encountered, or something they felt was missing.
The idea wasn’t to directly adjust these flows as a result of this workshop. My secret plan was to get everyone understanding and remembering the user needs so that their feedback and ideas throughout the project would be much more user-focused.
And it actually worked. Even now, nearly a year later, I still have senior stakeholders referring to the personas by name and talking about their needs and frustrations in meetings. I no longer need to interject every few minutes to speak up for the user. I can just sit back and relax! (Just kidding. A UX researcher’s job is never done!)
Something very important to remember with this approach is that IT IS NOT A REPLACEMENT FOR DOING ACTUAL USER RESEARCH!
It requires a lot of foundational user research to have already been conducted and analysed. It’s a communication tool, NOT a research methodology. Do not jump to this if you don’t feel confident that you have a solid understanding of your users’ motivations and needs yet, as it will only serve to confuse your team and make them question the reliability of later research.
Tracking the progress of your research recommendations
An important part of this process is keeping track of what action has been taken on your user research findings. At FanDuel, we use Jira for this. Jira is the tool used by our development teams, so we can create issues and track them through to development.
However, some teams use research repositories for this purpose or tools such as Aurelius or Dovetail. Find what works best for you and your team. Make sure that your research findings are easily accessed and searchable, to make it as easy as possible for your team to take action on them.
When these methods don’t work
The techniques I’ve described require a base level of understanding and trust between you, as the researcher, and the teams and stakeholders you work with. Not everyone works in an environment where this is the case.
The good news is that you can start to create and cultivate this environment yourself!
Develop persuasion skills
As an introvert, the word persuasion makes my stomach turn over. When I hear that word, I envision some great speaker from history, preaching to crowds of people, exuding charisma and charm.
What I’ve actually learned is that persuasion isn’t about who can shout the loudest. You don’t need to be outgoing to be persuasive. And it’s not all about playing mind games either.
Persuasion starts with understanding the person you’re trying to persuade. Apply your UX research skills to your colleagues. Try to understand what their motivations are. What pain points do they encounter trying to achieve their goals? If they don’t seem interested or convinced by your research, or the concept of user research in general, why is that?
Identify the ways that your goals relate to their goals. Say their concerns back to them; show them that you understand where they’re coming from. Then, show them the ways in which your end goals align and how your recommendations can help to achieve them. Use metaphors and comparisons to help them see things from your perspective.
Use hard facts
Seek out additional data to instil confidence in your user research findings. Using analytics to add context to any qualitative research findings is a no-brainer, but you may also be able to utilise existing research studies done outside of your company, academic reviews, statistics and articles to strengthen your findings.
This is especially important when carrying out UX reviews or giving feedback on designs; being able to back up what you’re saying with evidence shows that you’re not just giving your subjective opinion.
However, if you find yourself searching for numbers and quantitative data just to appease your sceptical colleagues, you likely need to spend some time justifying your methodology and explaining why it’s effective instead.
Be open and honest
Why does Nielsen say that testing with five users will suffice? Are you sure that’s true? How does he know? Why can’t we ask users to talk through the interface and explain why they will or won’t use it? Can we test multiple designs with the same participant? Why? Why not?
These are all questions I’ve been asked throughout my career. My initial reaction was to silently seethe at their questioning of my ability. How dare they? They wouldn’t ask a developer why they code a certain way!
“This is a fundamental UX research principle. Every researcher does it this way,” was how I’d answer.
The truth was, I didn’t really know the answers to those questions.
As I mentioned before, UX Research is still a relatively new field. Many of us have ended up here, rather than having consciously decided to embark on this career path through studying it in school.
That means we’ve learned on the job, through our experiences, and from books by UX gurus. These books are excellent at teaching us what to do and which mantras to chant, but they often fail to explain why we’ve come to favour these methodologies in the first place.
It can be tempting to make something up to satisfy your colleague or to become combative and insist you know what you’re doing, but I actually think being honest is the best policy.
Tell your colleague when you don’t know the answer to their question. Find out the answer and get back to them. Familiarise yourself with the history of UX Research and why we do things this way; I recommend reading David Travis’ book Think Like a UX Researcher as a start. Try to view these questions as innocent curiosity rather than an insult to your abilities.
Encourage face time with the users
The more exposure to your users that your colleagues have, the less time you’ll need to spend persuading them in the first place. This one’s a no brainer. However, you’ll likely need to be creative in incentivising your team to observe your sessions — at least initially.
“The most effective design teams get two hours of exposure to users every six weeks.” — Jared Spool (paraphrased)
Sometimes it’s just not possible to attend a set of sessions, due to calendars and conflicting meetings. Instead, what you can do is record your sessions and then set up a time when your colleagues are available, and play the videos of the sessions.
I find that setting up a meeting to do this is more effective than sending the videos out for people to watch in their own time (hint: they never do).
Watching at least a couple of sessions in their entirety often gives your team more context that they’d miss just from seeing the research insights and recommendations alone.
Use videos
Try to use video clips in your playbacks of user sessions whenever possible. I used to use video clips as a way to prove that the insights I was presenting weren’t just fabricated and that users really said these things (see!). I would sift through hours of footage, creating a supercut of different users saying the same thing over and over (see how much of an issue this thing is, team?).
While in some cases this can be impactful, generally I’ve found this approach to be counter-intuitive. What you really end up with is a monotonous video of the same message being repeated over and over, and you risk losing your audience — rather than convincing them.
Instead, what I do now is view session recordings as a way of saving my voice and allowing the user to express their issue directly to my team. I select only the most significant moments from the research. I’m picky with what makes it to the supercut. I look for the bits that surprise my colleagues, the bits they’ll remember and think about later.
On the flip side, when I’m presenting back a usability problem within a flow, I’ll often make my team sit through every excruciating minute of the user struggling to use the thing they’ve all built. And I won’t say a word. I keep the video running even after I can see everyone shifting around in their seats, smiling uncomfortably, internally screaming “WE GET IT! TURN IT OFF!”
Be patient
I’ve actually never joined a team of people who completely understood what I was there to do and was bought in from day one. I believe part of our job as researchers is to educate others on the value of our role. This can feel demeaning and demoralising at times, but it’s the reality of working in a field like UX Research.
I think that one of the things that are often missing from UX researcher job descriptions is being a good teacher. I don’t mind teaching my colleagues about UX; I actually quite enjoy it.
It can be understandably difficult for some stakeholders to appreciate the value we bring right away, particularly if they’re used to doing things a certain way. We don’t necessarily produce tangible outputs like code or designs. We don’t have the time to create lengthy research papers like in academia (and even if we did, who has time to read them?).
Being patient, resilient and relentless are traits I didn’t necessarily begin my career with, but that I’ve learned to develop over the years.
However, there is a fine line between educating others on the value of UX and arguing for your right to be there in the first place.
I think a small dose of scepticism is necessary when consuming information in today’s day and age, and I don’t see my research as being an exception to that rule.
But it’s not your job to convince people who are being combative, aggressive, and refusing to listen. Respect is absolutely essential. If you feel that you’re not getting that from the people you work with, then that’s another matter entirely.
Being able to assess when you’re in an environment where progress is possible vs fighting an uphill battle is essential when you work at a company with low UX maturity. If improving the UX maturity is not obtainable with the resources you’ve got, then move on! There are plenty of companies out there who will value your skills. Don’t spoil your passion.
Conclusion
Conducting quality UX research is only the first step. Communicating research findings to your team and convincing them to take action is arguably the most important part of your job. There’s no use in spending lots of time conducting painstaking research if your users never get to see any benefit from it in the end.
This quote from Caroline Jarett sums it up perfectly: “User researcher’s fallacy: ‘My job is to learn about users’. Truth: ‘My job is to help my team learn about users’”.
Using these techniques and advice, I hope you’ll be able to elevate your user research to the next level — and make it really matter to your team.
