hello@grailinsights.com
How To Get UX Research Deliverables You Can Actually Use

How To Get Ux Research Deliverables You Can Actually Use

By Kelly Valade, VP of UX & Design Research | May 18, 2021

A UX Research Process with the Client End User in Mind

UX researchers work so hard to ask the right questions in our research design . . . why aren't we doing that when we design our UX research deliverables?

Over the past 20+ years in UX Research, I’ve seen how often my client team members are each looking for something different from the same research project. Everyone is invested in product success, but each stakeholder plays a different role and needs different knowledge.

The UX research process should always take multiple stakeholder questions into account in the research design. That means designers, product marketers, product managers, executives, engineers, market researchers, data scientists, compliance teams, finance, etc. But making sure the UX research deliverable is actionable for everyone is another story.

Don’t get me wrong, I love a juicy research report filled with rich, creamy insights, visuals to provide context, and video clips to build empathy. My clients love these too. But early in my career, I heard clients ask, "There is so much here - so what should we tackle first?" 

That’s when I set out to change the UX research process with a focus on the deliverable. Teams need help prioritizing findings and mapping action items to the right stakeholder. Over the years I have developed a deliverable that’s customized to match my client’s product development timeline, giving all stakeholders an understanding of what they need to do and when. (Oh, and you get all the juicy insights bits too!)

My clients are my end users.

Just to back up a little, I spent the first decade of my career fine-tuning my ability to identify usability problems and diagnosing their root causes through the right balance of observation and conversational probing. I’d then build a powerful story in the form of a detailed report that clients found particularly effective for:

This is still true today. But now I ensure that my findings are usable too. After all, clients obsess over their products being usable. So my products should be usable. I focus on fine-tuning my analyses so it is both useful and actionable for my end users. And I approach this with the same lens I use when I approach research design.

UX Research Tools: A Needs-Based Segmentation of UX Research Stakeholders

Early on I realized that I needed to understand who will be the end user of my UX Research analysis. The answer was almost always: A variety of folks (or, everyone wants to see it!). 

I needed to understand what they wanted to learn and how they would use the report. I discovered that many of these folks had very different needs. 

Designers
Product Marketers
Product Managers
Executives
Engineers
Data Scientists
Market Researchers

A UX Research Process that Answers: “What should we tackle first?”

Reports are most useful when they organize findings by the problem type or by design specialty (e.g., experience designer, information architecture, interaction design, user experience design, etc.). But UX researchers also need to effectively convey how designers, engineers, and product managers should prioritize fixing those problems. 

Answering “What should we tackle first?” felt complex. I could tell them what the user needs them to fix first - after all, that is my job: to be the user’s advocate. I could also tell them how persistent a problem might be for their user base. But (as much as I hate it to be true) most businesses can’t survive by prioritizing only the needs of the user. Businesses also have to factor in the capabilities and needs of the business. As a consultant, I don’t always have visibility into their company goals, the product team’s KPIs, the back end systems they have to wrangle, the resources they have, or the amount of effort it takes to fix the more complex usability problems.

I started thinking about the workflows of my report users. And I realized that many of them use lists or backlogs - especially as they get closer to launch. I realized if I wanted my findings to be useful and actionable, I needed to provide a deliverable that is more compatible with their existing workflows.

That’s when I developed the Usability Problems Action Sheet (UPAS). Okay, it’s a spreadsheet. But a super usable one. It includes an exhaustive list of usability problems and any identified bugs. Each problem includes quotes from respondents (for context) and instructions for replicating the issue. UPAS assigns every problem with a severity rating and a rating for how pervasive the problem would likely be in the real world. Those ratings are combined with various business drivers to calculate an overall score that can be used in prioritizing the usability fixes.

This has been, by far, the most useful deliverable for designers, engineers, and product managers. When I first start working with a team, they struggle to wrap their heads around how a spreadsheet can be a useful deliverable. But I find that many of the hands-on fixers eventually ditch the formal report and rely solely on UPAS.

Think of UPAS as a team roadmap with individualized directions:

Designers see the problem their solutions need to solve. Engineers understand why they are building the solutions. The Product Manager has a backlog and the confidence to build out their plan. The Product Marketer knows how to talk to potential users about the benefits of using the product - well in advance of the launch.

The team is completely aligned in terms of what needs to be done, how it should be done, and why it’s important. 

Need an actionable UX research process to launch your next product? Let’s talk UPAS! Get UX research deliverables you can actually use.

Reach out at hello@grailinsights.com

Design for People with User Experience Research
I'm curious

I’d like to receive occasional news and insights from Grail.

Featured Insights