How to run usability testing that surfaces real friction

The first round of usability testing most teams run looks like this: a PM books five thirty-minute calls, builds a Figma prototype, writes a five-question script that starts with "what do you think of this?", and finishes the week with a Notion page of paraphrased reactions and a "let's move forward" decision. Two months later, the launched feature ships, the funnel doesn't move, the team blames "edge cases", and the next round of usability testing starts the same way.

The method is right. The question is how to run usability testing in a way the data survives translation into a decision. Done in the shape Jakob Nielsen and Tom Landauer wrote it, the method returns the most cost-efficient research data a product team can get: five participants, the right task, the right scenario, and a severity-ranked list of friction points the team can fix. Done in the shape most teams run it, it returns a transcript of polite reactions to a prototype the team already wanted to ship.

This is a working playbook: what the method is, the failure modes that turn it into theater, the six steps that work in 2026, and what changes when the recording carries voice as well as cursor.

What usability testing is

Usability testing is a research method, run on a working artifact (a prototype, a feature, or a live product), in which a small number of participants attempt a defined task and the team observes what goes wrong. The output is a severity-ranked list of friction points the team can fix before launch, or fix after launch once the data shows which fix matters most. The method is anchored in ISO 9241-11's definition of usability (effectiveness, efficiency, satisfaction) and developed for practitioners by Jakob Nielsen and Tom Landauer's 1993 work on the five-user rule.

Usability testing sits downstream of concept testing and upstream of launch metrics. Concept testing answers "does this idea solve a real problem". Usability testing answers "can a real user finish the task the design wants them to finish". Launch metrics answer "did the population behave the way the test predicted". A team that skips usability testing learns the answer to the third question only after committing to a build the test would have killed.

Why most usability tests don't surface real friction

Three failure modes show up across most usability tests that came back clean and shipped broken. Each one is structural, not effort-related. All three appear together more often than not.

The first is task as preamble, not as the test. The session opens with twenty minutes of "tell us about your role" and "how do you feel about the current product", then runs out of time for the actual task. The friction lives in the task. Everything before the task is calibration that should have happened on the recruitment screener.

The second is moderated leading. A trained moderator can stay neutral; an untrained one cannot. A PM who built the prototype watches the participant hover on the wrong button and asks "what are you trying to do?" instead of waiting. The friction is the participant not knowing what to do next. The question turned the friction into a tutorial.

The third is success measured in completion, not severity. The participant finished the task. That is the headline. What gets buried is that they finished it on the third attempt, with a four-second pause on the primary CTA, after misreading the field label twice and recovering only because the moderator nodded encouragingly. Completion rate without severity is a lying summary statistic.

How to run usability testing, step by step

Six steps. The first three are where most usability tests fail before the participant arrives. Steps four through six are where the data either lands or evaporates.

01 · Pick the task before the script

The task is the unit of usability testing. One task per session is the floor; two is the working maximum. A session that tries to test six tasks ends up running six bad usability tests at once and producing six paragraphs of paraphrased reactions instead of six findings the team can rank.

Write the task as a single sentence the participant can read aloud: "Imagine you just received a project handoff from a teammate. Find the file they shared with you and download it." Specific verb (find, download), specific object (the file the teammate shared), specific context (the handoff). No instructions on which menu to use. No hints. The task is the test; the steps to complete it are the variable.

If the task feels too easy when you read it back, it is calibrated for the team's mental model, not the user's. Run it past someone who has never used the product. If they ask three clarifying questions before starting, the task is good; rewrite it only when the question is "what is the product".

02 · Recruit the user who actually does the task

Five participants is the floor for a single homogeneous user group on a single task, per the Nielsen and Landauer model: five participants surface about 85 percent of severe usability problems on a defined task. The model assumes participants are drawn from the same persona. Two personas means ten participants. Three personas means fifteen. The longer treatment of sample size sits in how many user interviews do you need.

The screener is built against behavior, not interest. "How often do you handle file handoffs in your day?" is a screener. "Are you interested in testing a new file-handoff tool?" is not. The first filters for users whose current behavior is observable evidence of the task they are about to attempt. The second filters for users willing to be polite about prototypes.

The screener should also disqualify your friendly customers. They already know the brand, the team, and the prototype's likely shape. Their data is a confidence reading on the relationship, not on the design. The piece on how to recruit user research participants covers the operational side of getting the right cohort in front of the test without polluting the sample.

03 · Write the scenario, not the questionnaire

The scenario is the artifact the participant lives inside while attempting the task. It is one short paragraph that gives them a situation, a goal, and a small constraint, and stops there. No instructions, no hints, no leading framing.

A bad scenario: "We've designed a new feature for sharing files. Please try clicking around and let us know what you think." A good scenario: "It's Monday morning. Your teammate sent you a Slack message before the weekend saying they'd shared a project file with you. You haven't replied yet. Open the tool and find the file they shared. You have five minutes."

The constraint matters. Five minutes is a number the participant feels. "Take your time" is a sentence the participant rounds up to fifteen minutes of polite exploration that never resolves into a finding. The piece on how to write user research questions covers the broader craft of prompts that land without the team in the room; usability scenarios are the application of that craft to behavior.

04 · Choose moderated, unmoderated, or async with think-aloud

Three valid modes, each with a different trade.

• Moderated. One researcher and one participant on a live call, the participant shares their screen, completes the task, narrates their thinking. Best when the prototype is fragile and needs hand-holding, when the participant is in an unfamiliar medium (accessibility research, enterprise B2B with a CFO), or when the task is exploratory enough that a live probe matters.
• Unmoderated. The participant alone with the prototype on a platform that records screen and think-aloud. Best when the prototype is robust, when the team needs more than five participants per persona, or when the participants live across enough time zones that scheduling is the bottleneck. The trade is the moderator's real-time probe for scale and a small honesty premium (the absence of an observer lowers the social cost of saying "this is broken"). The companion piece on how to run unmoderated user research covers the operational details.
• Async with think-aloud and AI probes. The newer shape: the participant records their screen and voice on their own time, an AI interviewer asks adaptive follow-ups when the participant says something vague or contradicts themselves, and the team gets a transcript plus a severity-ranked synthesis the next morning. Best when the team wants moderated-quality probing at unmoderated scale. The depth of the AI probe is configurable (shallow, medium, or expert) per task. Usability sessions usually want medium on first-attempt failures and expert on near-misses where the participant recovered but the path was wrong.

The wrong choice is "we always do moderated" or "we always do unmoderated". The right choice changes per task.

05 · Probe the friction, not the score

The first answer to "did that work for you?" is almost always "yeah, mostly". The real friction lives in the second turn. This is the place where adaptive follow-up probes earn their keep.

Three reliable probe patterns, one per moment in the task:

• On a pause. The participant stops moving the cursor for more than three seconds. Probe: "What are you thinking right now?" Not "what are you trying to do?" The first preserves the friction; the second turns it into instruction.
• On a recovery. The participant tries something, backs out, tries something else. Probe: "What made you change direction?" The recovery is the data; the reason is the finding.
• On a completion. The participant finishes the task. Probe: "What would have made that easier?" Not "did you like it?" The first surfaces friction; the second surfaces politeness.

Configurable probing depth matters here. A shallow probe asks one clarifier and stops. A medium probe asks a small chain when the answer is vague or contradicts itself. An expert probe keeps going until the AI has the context a senior researcher would dig out in a moderated interview: scope, alternatives tried, prior attempts, who and when. The participant can skip on every probe. For usability work, medium is the default; expert is the right call on the moments where the participant says "I figured it out eventually". The longer treatment of how the depth decision works sits in how AI follow-up questions work in user research.

"Yeah, I got there in the end. I mean, I clicked on the wrong thing twice, but then I realized the share button was hidden in the corner. I think I'd give up if I weren't being recorded."

The reversal in the pull-quote is the entire point of the second turn. The first answer was "I got there in the end" (a pass). The probe asked one more layer. The honest answer arrived in turn two: the participant would not have completed the task on a normal day, the share button is in the wrong place, and the severity is high. None of that was in the first answer.

06 · Synthesize by severity, not by participant

The common synthesis error is to read the session transcripts participant-by-participant and list "what each person said". That list is sorted by the wrong dimension. The right unit of synthesis is the friction point, ranked by severity across the sample.

A working severity scale, adapted from Nielsen's severity ratings for usability problems:

• Critical. Task failure, or a workaround that most users will not find. Fix before launch.
• High. Task completed but with significant friction (more than one recovery, a pause longer than five seconds, an error the user noticed and corrected). Fix in the next sprint.
• Medium. Mild friction, completed task, the user mentioned it on the probe. Track and fix when the surrounding area is touched.
• Low. Cosmetic, preference-level, mentioned by one participant. Note it and move on.

Two patterns to look for in the sorted list. First, the same friction point named by more than two participants in different words: a fix priority, regardless of the wording. Second, a single participant's critical that no one else hit: usually a recruit who is wrong for the persona, sometimes a real edge case that matters for accessibility or onboarding. Pull the moments by severity; let the participants disappear into the source column. The general pass on synthesis is in how to analyze user interview transcripts.

When to run usability testing internally before customers see it

The instrument also works inside the company, and running it internally first usually saves a round of external testing. Before the prototype goes to customers, share the same scenario and the same task with engineering, design, support, sales, and anyone else whose mental model will collide with the build.

Engineering will hit the edge case the design assumes away. Support will recognize the friction pattern from existing tickets and tell you it has been a problem for eighteen months. Sales will hit the demo-day moment that confuses every prospect. Each of those is recoverable from a meeting; the meeting tends not to happen until the build has started.

The async version of the internal round is a study link shared in internal channels. Engineering, design, support, legal: each runs the same task at their own desk, the AI asks the same probes, the team gets a synthesized severity-ranked list of every internal stakeholder's friction in less time than scheduling the meeting would have taken. The pre-launch sanity check is where the internal version of usability testing pays off most reliably.

Where to put the usability link continuously

A usability test does not have to be a one-time campaign. The same study link can live in places that produce ongoing usability signal:

• A persistent in-product link. A small "report friction here" affordance on the screen the team is currently iterating. Users report what is broken in the moment, not three weeks later in a recruited session.
• The cancellation or downgrade flow. Users who just left, asked one task-anchored question about the screen that pushed them, will tell the team things a satisfied-cohort interview will never surface.
• Post-onboarding moments. First successful task complete, day-seven retention check, first export, first invitation sent. Each is a natural moment to ask "what was the worst part of getting here".
• Owned distribution. A link in a customer newsletter or a partner round-up, anchored to a specific screen, returns usability data from users the recruiter does not have a list for.

The framing: a Talkful study link is a standing instrument, not a one-off campaign. The companion piece on how to build a customer feedback loop covers the broader continuous-feedback pattern; usability testing fits inside it as the scoped, task-anchored layer.

When voice catches what a screen recording misses

Voice is one of four input modes in usability testing (voice, text, choice, rating), and the modality choice depends on what the team wants to recover. Screen recording captures the cursor path, the click sequence, and the failure point. Voice captures what the recording cannot: the half-second pause before "yeah, I think so", the "I dunno..." that prefaces a reversal, the energy that gets faster on a recovery and slower on confusion. The detail of the asymmetry sits in what voice catches that text loses.

For usability work specifically, voice carries the most weight on the probe layer. Letting the participant talk while recovering, instead of typing a reflective answer afterward, returns the friction at the moment it happened, not after the participant has rationalized it. The completion confirmation can be a single choice or rating; the moment-of-friction probe should almost always be voice, with text as a graceful fallback for participants who cannot record.

When usability testing is not the right tool

Three cases where running a usability test returns a number that is not the answer.

The product is not built yet. Usability testing on a marketing landing page is concept testing. Usability testing on a value proposition is also concept testing. The method assumes there is an artifact to attempt a task on. The piece on how to run concept testing without faking the result covers the upstream method.

The question is "do users want this", not "can users do this". Usability testing measures friction on a task the team has already decided is worth doing. It does not measure demand. A usable product nobody wants is a clean usability test in a market that does not exist. Run a jobs-to-be-done switch interview first: see how to run jobs to be done interviews.

The cohort is too small to recruit cleanly. Three users from a niche segment, plus the founder's network, is not a usability test. It is a friend-of-the-team review. If the persona is genuinely rare, the right answer is to extend recruitment time, not to compress the sample.

How usability testing relates to other research methods

Usability testing is one tool in a wider product-research practice. The shorthand:

• Concept testing sits before usability testing, on a value proposition or idea, with no artifact to attempt. Concept testing answers "is this worth building". Usability testing answers "can it be used".
• Jobs to be done interviews sit upstream of both, on the switch moment that motivated the build. JTBD answers "why would the user change behavior".
• The product-market fit survey sits downstream, on customers who already use the product. PMF answers "would they miss it if it disappeared". See how to run a product-market fit survey.
• Continuous discovery interviews run weekly on the existing customer base. Usability testing inserts when a specific build needs friction-level validation; the weekly rhythm carries on around it. See continuous discovery interviews.

All four sit inside the wider practice covered in the voice user research guide. Discovery research finds the problem, concept testing validates the framing, usability testing validates the build, PMF measures the fit.

FAQ

What is usability testing in user research?

Usability testing is a research method, run on a working artifact (a prototype, a feature, or a live product), in which participants attempt a defined task and the team observes what goes wrong. A well-run usability test returns a severity-ranked list of friction points the team can fix, anchored to recordings of real users attempting real tasks. The method assumes the participant has the problem the product is built to solve and is competent in the broader category; what it measures is the gap between the design's mental model and the user's.

How many participants do you need for a usability test?

Five participants per homogeneous persona on a single task, per the Nielsen and Landauer 1993 model: five users surface about 85 percent of severe usability problems. The number scales with personas, not with study importance. Two personas needs ten participants; three needs fifteen. Below five, one strange reaction can move the apparent result; above ten on a single persona, marginal returns drop fast unless the task is genuinely complex. The longer treatment is in how many user interviews do you need.

What is the difference between moderated and unmoderated usability testing?

Moderated usability testing is a live session, one researcher and one participant on a call, with the participant sharing their screen and the moderator probing in real time. Unmoderated usability testing is the participant alone with the prototype, recording screen and voice through a tool, with the team reviewing the output afterwards. Moderated returns deeper signal on one decision; unmoderated returns more participants per week at lower friction. The newer async-with-AI-probes mode sits between them: unmoderated cost, with adaptive follow-ups that approximate the moderator's real-time probe.

What are usability testing scenarios?

A usability testing scenario is a short paragraph that gives the participant a situation, a goal, and a constraint, and stops there. The scenario does not include instructions or hints; those would defeat the test. A well-written scenario reads like a paragraph a teammate would send: "It's Monday morning, your colleague shared a file with you on Friday, you haven't replied yet. Open the tool, find the file they shared, you have five minutes." Specific verb, specific object, specific constraint. The participant fills in the gaps; the gaps are the test.

Should you run usability testing remotely or in person?

For most product teams in 2026, remotely. In-person usability testing carries a scheduling and logistics cost that has stopped being worth the marginal signal in most cases, and remote tools have improved enough that the screen recording, voice capture, and probe quality are at parity. In-person is still the right call for accessibility research with assistive technology, for hardware products, and for tasks that require a controlled physical environment. The Nielsen Norman Group's guidance on remote usability testing is the clean reference on the trade-off.

How do you analyze usability testing results?

Synthesize by friction point, not by participant. List every moment of friction across the sessions, group the ones that repeat, rank the list by severity (critical, high, medium, low), and pull one transcript clip and one screen-recording moment per ranked item as the evidence column. Resist the impulse to summarize participant-by-participant; that list is sorted by the wrong dimension. The longer treatment of qualitative synthesis sits in how to analyze user interview transcripts.

---

Usability testing fails when the task is a preamble to a conversation, the moderator is a tutor, and the synthesis is a paraphrased Notion page. It works when the task is one sentence, the scenario is one paragraph, the participant attempts it alone or with an adaptive probe that knows when to ask one more question, and the synthesis returns a severity-ranked list the team can act on this week. Talkful is built for the second shape: a study link goes out, participants answer in voice, text, choice, or rating, the AI interviewer probes the polite first answers into the honest second ones, and the synthesis engine returns themes, quotes, and citations the team can ship from and the agents you build with can act on. The wider voice user research guide covers where the method sits inside a continuous practice.