Usability testing means watching real people attempt real tasks with your design, so you can see where it helps them and where it fails them.
The setup is simple. You give a participant a realistic goal, like "find a hotel room for two adults next weekend and book it," and then you watch what they actually do. You don't guide them, you don't explain the interface, and you don't defend your decisions. You observe where they hesitate, where they take a wrong turn, and where they give up.
It helps to be equally clear about what usability testing is not. A usability test is not a focus group, not a demo, and not a survey asking people whether they like your design. A focus group collects opinions from a room; a test collects behavior from one person at a time. A demo shows people what your product can do; a test asks them to do something and gets out of the way. And "do you like it?" tells you almost nothing, because people can love the look of a checkout flow they can't actually complete.
If interviews already exist, why not just ask users whether the design works? Because people are poor reporters of their own behavior. Not because they lie, but because most of what we do with an interface happens on autopilot. A user who fumbled with your filters for a full minute will honestly summarize the session as "it was fine."
People also want to be kind. Sitting across from the person who built something, most of us soften our criticism. Behavior doesn't soften anything. If a participant taps the wrong icon three times in a row, that fact sits on the table no matter how politely they describe the experience afterward.
In a usability test, what people do outranks what they say.
That doesn't make their words useless. Asking participants to think aloud while they work, narrating what they expect and what confuses them, gives you the "why" behind the behavior. The rule is about priority: when the words and the actions disagree, trust the actions.
Usability tests come in two broad flavors, and knowing which one you're running keeps your goals honest.
Formative testing happens while the design is still forming. You test early versions, sometimes rough ones, to find problems while they're still cheap to fix. The output isn't a score; it's a list of specific issues: users didn't notice the "save" action, the label "manage plan" meant nothing to anyone, step three of onboarding felt like an error page. Formative testing exists to change the design, not to grade it. This is the kind of testing you'll run most often, and you can run it many times on the same product.
Summative testing happens when a design is close to done or already shipped. Here you're measuring rather than exploring: how many participants complete the task, how long it takes them, how many errors they make. Those numbers become benchmarks you can compare against a previous release, a competitor, or a target the team agreed on. Summative results tell you whether the design is good enough; they're less useful for telling you what to fix.
Newcomers often assume a usability test needs dozens of participants to mean anything. In practice, a handful is enough, and here's the logic. If a button label genuinely confuses people, it will confuse your first few participants, not just the thirtieth. Serious usability problems are not shy; they show up early and repeatedly.
A small group of participants will surface most of a design's major usability problems, and each additional person mostly re-discovers issues you've already seen. Past a certain point, another participant costs you a session and teaches you almost nothing new.
That leads to a more useful way to spend your effort: more rounds of testing beat more users per round. Test with a few people, fix what they exposed, then test the revised design with a few more. Two small rounds tell you both what was broken and whether your fix actually worked. One giant round only tells you what was broken, in exhausting detail.
Anything a person can attempt a task with is testable. That includes a paper prototype you sketched this morning, a clickable prototype stitched together in a tool like Figma, a half-built development version, and the product that shipped last year. You are never too early to test; you can only be too late.
The fidelity of the design changes what you learn, not whether you can learn. A paper prototype won't reveal load-time frustrations, but it will reveal whether your flow makes sense and your labels carry meaning, and those are exactly the problems worth catching before anyone writes code. Testing a live product, meanwhile, catches the friction that only appears when everything is real: actual data, actual speed, actual mistakes.
In a usability test, the product is being tested. The user is not, and neither are you.
This matters in both directions. Participants often blame themselves when they struggle, apologizing with "sorry, I'm not very technical." Part of your job is to make clear, before and during the session, that nothing they do can be wrong. If they get lost, the design lost them.
The same grace applies to you. Watching someone struggle with a screen you were proud of stings, and the temptation to jump in and explain is real. Resist it. Every rescue erases the exact evidence you came for. Designers who learn to sit quietly through that discomfort come out with better products, because a usability test that finds nothing wrong usually means the test was too gentle, not that the design is perfect.
This is also where testing earns its place in the design process. You've already researched, defined the problem, ideated, and built wireframes and prototypes; testing is how the iterate loop closes. Observe, fix, and test again, and each pass through the loop trades a little of your ego for a lot of your users' success.
Usability testing is watching, not asking: real people, real tasks, and your design under honest pressure. Run formative tests early and often to improve the design, and summative tests late to measure it against benchmarks. Keep your samples small and your rounds frequent, test at any fidelity from paper onward, and remember that every session is judging the product, never the person using it.