Usability testing vs. user testing vs. session replay: what each one actually catches

“User testing” and “usability testing” are used as synonyms constantly, including by tools that sell one and call it the other. It’s worth being precise, because the imprecision is why teams end up running the wrong kind of research for the question they actually have.

The terms, precisely

Usability testing is narrow: can a person accomplish a specific task using this interface, and where do they get stuck? It’s normally moderated, scripted, and measures completion and friction against a defined task.

User testing is the broader umbrella — usability testing is one kind of user testing, but so is a concept test, a card sort, a preference test, or an open-ended interview about how someone currently solves a problem. If someone says “we’re doing user testing” without qualifying it, ask what task or question it’s actually structured around, because the methods and the output look nothing alike.

Session replay isn’t user testing at all, in the sense that no one is being tested. It’s an observational record of real usage with no task assigned and no researcher present. It answers a different category of question — see session replay vs. usability testing for the full comparison.

What usability testing catches that nothing else does

A moderated usability test is the only method here where you can ask “why” in the moment. A participant hesitates on a form field, and you can ask what they expected to happen — immediately, while the confusion is still fresh in their head. Session replay shows you the hesitation. It cannot ask the question.

It’s also the only method that works before launch. If the feature is behind a flag, or exists only as a prototype, there’s no real usage to observe yet. Usability testing is what you run when the thing you’re studying doesn’t have users yet.

What broader user testing catches that usability testing doesn’t

A usability test assumes the task is right and tests whether the interface supports it. It won’t tell you the task is wrong — that people don’t actually want to do the thing you built a flow for. That’s a different research question (concept testing, interviews, jobs-to-be-done work), and usability testing will happily report “100% task completion” on a feature nobody needed.

What session replay catches that neither does

Both usability testing and broader user testing are, definitionally, research you decided to run. You picked the task, recruited the participants, and scheduled the sessions. Whatever happens outside that window — a bug that only shows up on a specific browser, a rage click on a button three weeks after a deploy that shouldn’t have changed it, a support ticket you can’t reproduce — none of that shows up in a study, because a study only sees what you thought to look for.

- ⚠ 0:19 rage click ×4 · button "Pay now"
- ⚠ 0:21 POST https://example.com/api/pay · 502

That’s a real UserTapes transcript line. Nobody scripted a task called “have your payment fail” — it happened, it got recorded, and it was searchable afterwards. That’s the category of problem session replay exists for: not “does the intended flow work,” but “what actually happened, including the things nobody anticipated.”

Picking the right one

• Building something new, nobody’s used it yet → usability testing
• Not sure if the thing you’re building solves a real problem → broader user testing (interviews, concept tests)
• Feature is live and something’s off, but you don’t know what → session replay, to find where, then a targeted usability test if you need to know why
• A specific person reported a specific problem → session replay, specifically — see how to reproduce a bug a user reported but you cannot trigger

Most mature research practices use all three at different points in the same project, not one instead of the others. The mistake isn’t picking the wrong method — it’s using whichever one you’re used to for every question, regardless of which question you’re actually asking.

---

For the “what actually happened” side of that list, UserTapes records real sessions and turns them into searchable transcripts rather than hours of video — 100 sessions free, no card required. See what a rage click is and how it’s detected for one example of a signal that only shows up in real usage, never in a script.