How to Get UX Research Deliverables You can Actually Use

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’s team members are each looking for something different from the same research project. Of course, everyone is invested in the product’s 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:

• Socializing the findings throughout the company
• Efficiently sharing key findings
• Creating empathy for the user
• Gaining alignment on initiatives
• Giving visibility into the new product/feature to other parts of the organization
• Resolving internal debates
• Creating alignment on product initiatives

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 would 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

• What they want: Most want to better understand how others interact with their designs to determine whether or not their work functions as it was intended. If the research uncovers problems, they want to understand the causes behind the problems so they can make the right changes to improve the experience.
• How they use UX research: This team needs to start creating solutions for the problems uncovered in the research. Once they understand the issue, they can start getting creative in designing a solution. They can also use these findings to better collaborate with engineering on their builds. Depending on the size, design teams can be divided by specialty (e.g., Experience Designer, Information Architect, Interaction Designer, Experience Architect, User Interface Designer, User Experience Designer).

Product Marketers

• What they want: They also want to better understand their audience of current and potential users so they can communicate with them in a way they will understand. Most will want to understand any differences that occur across the audiences included in the research. UX research helps them empathize with the user and can surface use-cases to leverage in marketing campaigns.
• How they use UX research: These folks will likely want to review the research and establish a clear understanding of how the products/features will be used. It is crucial for the product marketers to understand how the research impacts what will or will not be included in the launch plans.

Product Managers

• What they want: Product managers are expected to be the CEOs of their products/product lines/features in most organizations. They typically want reassurance that the product still has product-market fit, the key product features are working well and meeting/exceeding user expectations, and it is on schedule for launch. There may also be internal debates about a feature or experience that they hope to resolve via the research findings. This data can help back up their decisions, justify efforts being put into internally controversial initiatives, and prioritize remaining work before launch (and even post-launch).
• How they use UX research: These leaders often want to use the findings for a few primary purposes: First, to share key aspects of the research with leadership (e.g., findings that resolve internal debates, findings that justify the build effort); Second, understand which aspects of the product work well and which are performing below expectations; and Third, prioritize the remaining work, so the project delivers the desired outcomes to users and the business and remains on schedule.

Executives

• What they want: They typically want reassurance that the product is on time, on schedule for launch, and that the product is meeting market demand. There may also be internal debates about a feature or experience that UX research data can help resolve.
• How they use UX research: Most are notoriously too busy to read detailed findings. Hence, the “executive summary” or “TL;DR” at the beginning of a report is their go-to source.

Engineers

• What they want: The findings can give engineers a more comprehensive understanding of how and what they are building will be used. It’s not uncommon for engineers to have opinions about the design—especially since they have to handle much of the back-end aspects of building the experiences. The research can help resolve internal debates and align perspectives across the organization.
• How they use UX research: The detailed findings from UX research often inspire creative and innovative ways of solving problems. They can also use these findings to better collaborate with design on their builds.

Data Scientists

• What they want: They like the research data to provide context to the “why?” questions they have about what is happening in their data. To trust the findings, however, they must feel the research methodology is solid.
• How they use UX research: They will likely utilize the findings to explain some of their more perplexing data. They may use the analysis to develop hypotheses for further testing.

Market Researchers

• What they want: These folks will either be the primary sponsor of the research or a collaborator. They have lots of knowledge about current and potential users, and they are hungry to learn more. What they don’t want is to duplicate research. UX researchers need to collaborate with these folks at every stage, as they may already have certain insights. This allows a researcher to focus on gathering entirely new insights.
• How they use UX research: As research sponsors, they often need to present findings internally to other teams in the organization. Regardless of their role in your research study, they will likely comb through the report and pull out the net-new findings. It’s also common for these findings to be added to future reports and presentations.

A UX Research Process that Answers: “What Should We Tackle First?”

Reports are most useful when they organize findings by the problem type or 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 user’s needs. 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, their resources, 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 that if I wanted my findings to be actionable, I needed to provide a more compatible deliverable 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. Finally, 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 on 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.