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:
- 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 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.
- 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 of 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 up by specialty (e.g., Experience Designer, Information Architect, Interaction Designer, Experience Architect, User Interface Designer, User Experience Designer).
- 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 that they will understand and engage. 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 be leveraged 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 especially important for the product marketers to understand how the research impacts what will, or will not be included in the launch plans.
- What they want: In most organizations, product managers are expected to be the CEOs of their products/product lines/features. 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 that it is on schedule for launch. There may also be internal debates about a feature or experience that they are hoping to be resolved via the research findings. This data can help back up their decisions, justify efforts being put into internally controversial initiatives, and prioritize remaining work prior to launch (and even post-launch).
- How they use UX research: These leaders often want to use the findings for a few primary purposes: 1. To share key aspects of the research with leadership (e.g., findings that resolve internal debates, findings that justify the build effort); 2. Understand which aspects of the product work well and which are performing below expectations; and 3. Prioritize the remaining work so the project delivers the desired outcomes to users and the business and remains on schedule.
- 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 the detailed findings of the report. Hence, the development of the “executive summary” or “TL;DR” that is commonly placed at the very beginning of the report to provide the key takeaways from the findings.
- What they want: The findings can give engineers a more comprehensive understanding of how 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.
- 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.
- 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. It is important for UX researchers 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 a research sponsor, 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 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 email@example.com