Topics
June 22, 2026
June 22, 2026
No one tells you the hardest part of a large-scale usability benchmark isn’t the logistics or the methodology. It’s the meeting where a stakeholder says, “I’m not sure that’s really a critical task.” Or, “That’s not our team’s problem.”
Suddenly, you’re not just a researcher presenting data. You’re an advocate defending it—in a room where everyone has their own backlog, their own roadmap pressures, and their own opinion on what matters. Defending research is nothing new for UX Researchers, but the stakes feel different when it’s company-wide research that touches virtually every team.
I learned this up close when my team set out to benchmark the most critical features of the LinkedIn app.
The goal was straightforward: identify friction, tie it to behavioral evidence and business impact, and create a shared prioritization framework that leadership and product teams could act on.
I learned early in my career that doing a rigorous study using the best social-scientific methods and analyses is not enough to convince a product team to change its roadmap. But I thought the benchmark might be different because it gave teams clear, practical fixes to improve their existing features or products.
Spoiler Alert: It’s still not enough. You need to bring your stakeholders along for the ride despite there being no interviews to watch or session debriefs to facilitate.
But how do you bring stakeholders along the journey when you’re testing an entire app? It’s not exactly feasible to bring hundreds of people with you while conducting unmoderated studies when you have only one researcher.
But to quote the title of Michael Scott’s unfinished book on business, ‘Somehow I Manage.’ And by ‘I’, I really mean Jake Silva, the Staff UX researcher on our UX Measurements team and the co-author of this paper.
So I’ll let him tell you how it happened.
We started with a simple idea on LinkedIn's UX Measurement team: complement the hundreds of business metrics teams use to evaluate product performance with a user-centric measure of product quality.
The goal was ambitious but straightforward. We wanted a metric that could track the quality of LinkedIn’s user experience, identify where members encounter friction, and help teams quantify the impact of design improvements over time.
At first, we approached this challenge like researchers. We…
But as we iterated on the benchmark, we realized that the traditional researcher playbook would only take us so far.
To get the company-wide impact we wanted, we had to update the playbook.
Product leaders needed a voice in what was measured, the quality metric had to be easy to understand, and we had to remain flexible as business priorities shifted.
Over time, the benchmark became a company-wide program that teams now use every six-month planning cycle to identify, prioritize, and address product quality issues.
The five lessons below come directly from this journey. Each one reflects a challenge we faced while trying to turn benchmark findings into action. Together, they helped move the conversation from "interesting research" to "What should we fix next?"
Before we ran a single session, we met with 11 product teams across the company to co-define what “critical” meant for their product, roadmap, and members. That sounds straightforward, but it wasn't. Each team voiced strong opinions on which tasks should be benchmarked.
So we had a choice. We could let the 11 teams define what tasks were most critical for them and spend the next few weeks arguing over what should make the cut.
Or, we could develop a framework to shift the conversation from opinions on “Is this a critical task?” to “Why is this a critical task?” We chose to go this route and used four criteria:
This matters because it moves you from “researcher says” to a shared logic. When your criteria are co-authored and signed off, the conversation changes. You’re not asking stakeholders to trust your instincts.
Instead, you’re asking them to engage with a framework that…
Defining what to benchmark was only half the problem. Next, we had to decide how to measure usability.
At first, we aimed for maximum rigor in our measure: z-scores, standard deviations, and normalized composites. Technically sound, but inscrutable for our stakeholders.
After candid feedback, we realized we couldn’t just build a metric for ourselves. We needed to build a tool for product teams to answer two questions: 1) how are we doing? and 2) what should we fix?
So we landed on a simple top-2-box metric we named the Product Quality Score. It rolled up multiple measures of the experience (ease, discoverability, control, interface responsiveness, etc.) into a single signal that answered the two questions product teams actually cared about.
And while a single intuitive score made the results easier to understand, it didn't make them any less useful. Low scores helped teams quickly identify where problems existed, and the usability videos helped explain why.
So when you’re building a company-wide benchmark, aim for balance: your organization needs to trust in your measure, but also understand it well enough to act on it.
Even with clarity on what to measure and how, another challenge remained: helping teams turn findings into actions.
For a single task, we might identify 10-15 issues contributing to a low Product Quality Score. With almost 50 tasks measured, we risked producing a lot of noise.
Our initial instinct was to hand off a list and say “fix these”. But that’s not how product teams work. They work on tradeoffs. Every potential fix competes with roadmap commitments, growth bets, and limited engineering time. So we risked our benchmark collecting dust on the proverbial research shelf if we didn’t deliver a stack-ranked list.
To do so, we built a prioritization framework which combined:
This gave teams a place to start. So instead of delivering a long list of 15 issues, we could say, “If you fix these top 2-3, you’ll meaningfully improve the experience and your overall Product Quality Score.” Now teams knew where to start and which fixes would have the biggest impact.
While you don’t necessarily have to follow our prioritization framework, make sure you have one that works to drive impact.
Even after you’ve agreed on the rules, the pushback will come.
Some teams will question whether the tasks you flagged as critical fall within their scope. Others won’t buy that a given flow is high-priority relative to their roadmap. A few will challenge whether benchmark tasks cleanly map to real behavior. Some might question whether identified usability friction is actually a problem.
Some of that is noise. But some is signal.
So keep in mind…
Here’s an example. We highlighted friction created by a necessary but unexpected paywall in a team's feature. The team’s stance was, “It works as expected.” For members, though, it felt like a surprising stop in the flow after they’d already invested meaningful effort.
Our response had to be clear and firm without being tone-deaf: “We can keep the paywall and still be member-centric. Add a subtle signal in the interface before they invest time, so the paywall isn’t a surprise.” It's not about saying no. It's about making it better for members.
In moments like these, your framework helps ground the conversation. You're not arguing from instinct or opinion; you're working from criteria everyone agreed to upfront. "I hear you—and given our criteria, this issue still matters. How can we make this work?"
Flexibility and holding your ground aren’t opposites. The craft is knowing which the moment calls for.
Be genuinely open when new information changes the calculus:
But beware the slippery slope from adaptability to capitulation. If you default to others’ priorities under pressure, you produce findings that are safe instead of useful. Benchmarks become rubber stamps for what teams already planned to do.
The answer isn’t stubbornness. It’s conviction. When your criteria are principled and your framework is clear, you can adapt without feeling like you abandoned the work.
If you’re planning a large-scale usability initiative, carry these into the room:
Our benchmark surfaced real friction across critical LinkedIn features and created a shared roadmap to address them. But the takeaway I carry forward isn’t a methodology or a matrix. It’s this:
Research doesn’t drive change by being correct. It drives change by being credible, well-grounded, and defended by someone who can hold the tension between adaptability and conviction.
Build your framework before you need to defend it. Know your criteria. And when the pushback comes—and it will—you can feel confident that you’ll have something to stand on.
Kevin Newton is Sr. Manager, UXR at LinkedIn, where they lead the UX Measurement Team running company-wide usability benchmarking, experimental-based in-product feedback, and product quality initiatives across the consumer experiences. Connect on LinkedIn!
Jake Silva is a mixed methods Staff UX Researcher at LinkedIn, where they lead the Quality Benchmarking, research 0-1 bets and explore strategic questions about the future of work and economic opportunity. Connect on LinkedIn!
.png)