Usability Test

For a long time the way to settle a design question was to gather the team around a finished screen and trade instincts. One person would say nobody will ever find that button where it is. Another would say they found it immediately, so it's fine. Neither claim rested on anything but the speaker's own experience, so the decision usually went to whoever argued hardest.

Asking users directly didn't help much either. Show someone a screen, ask what they think of it, and most people say it looks fine. It's awkward to criticize something in front of the person who built it, and skimming a layout is a different act from using it. Screens that collected a round of "looks fine" shipped anyway, and then came back as support tickets — twenty a day from people who couldn't work out where the invite link gets created.

A usability test replaces the asking with watching, which sidesteps both problems at once. You don't collect opinions, you assign a task. You say "invite a teammate to this document," then stop talking and watch which menu the person opens first and where their hand stops moving. Nobody has to tell you they can't find it; you see them not finding it.

Write a short list of tasks, recruit about five people who match your real users, put them through the tasks one at a time, and record where each person gets stuck. Budget 30 to 60 minutes per person.

1. Turn the thing you want to learn into a task. If you want to know whether inviting people is easy, don't ask anyone to evaluate the invite feature — tell them to make this document visible to two teammates. Keep it to three to five tasks, which is about what fits in an hour.
2. Recruit for the same conditions your real users work under. If you want to see how someone in a team of five or more creates documents, a participant who works alone will get stuck in entirely different places. Five people is enough. The problems that matter usually surface with the first three, and from the sixth person on it repeats.
3. Set expectations before you start. Say plainly that the screen is what's under test, not the person, and that getting stuck is the exact thing you came for. Skip that and participants spend the session hiding the fact that they're struggling, which distorts everything you record.
4. Let them work and keep quiet. When someone stalls it's tempting to offer a hint, but that silence is the data you came to collect. Asking people to think out loud also shows why they opened that particular menu.
5. Record an outcome and a duration for each task. Sort outcomes into three buckets: finished unaided, finished with help, didn't finish. Note the spot where each person stalled.
6. Lay the five records side by side and rank problems by how many people hit them. Four out of five stopping at the same place goes straight to the top of the fix list. A spot where only one person stopped may just be that person's habit, so it waits.

The method fits best when something clickable already exists. Because participants use their hands, there has to be something to use. That puts the method after the decision about what to build, not before it: it checks whether the chosen thing works, and it can't tell you what to choose.

It also fits when a number has flagged a problem and you need the reason behind it. Analytics will tell you half the people who start signing up never finish; it won't tell you why. Run five people through the same screen and the reason arrives as a scene — the verification email lands in spam, so nobody gets to the next step.

Three limits are worth knowing. First, it produces no percentages. Four out of five getting stuck does not mean 80 percent of your users get stuck. If you need a proportion, run a survey that asks hundreds of people the same question, or count events in your logs. Second, it answers whether something is easy to use, not whether anyone wants it. Third, a session is not real life. With an observer in the room, participants push through obstacles they would normally abandon, and in their own week they'd simply close the tab at the same spot. To close that gap, go watch people where they actually work with field research, or have them keep a record for two weeks in a diary study.

"Let's run a usability test on this flow before we decide."

Stop arguing from opinion and let five people's records settle it.

"Four of the five couldn't find the invite button. Let's move it first."

The same failure repeated, so it's the screen's problem rather than a personal habit.

"That's not a usability problem, the feature just isn't there. A test won't surface it."

The question can't be answered by watching someone attempt a task, so use another method.

At Pagedeck, whenever Noa builds a new version of the invite flow, five people sit down with it before it ships. Three tasks: make one document visible to two teammates, change one of those teammates to read-only, and create a link an outside client can open. Noa runs the session while Mia logs where people stall and for how long.

In the first round, four of the five stopped on the second task. The control for changing someone's permission was tucked behind a three-dot menu next to their name. Noa pulled it out where it could be seen, revised the prototype, and two days later gave the same three tasks to a different set of five. This time all five finished.

The most common mistake is assuming a study needs many participants to be trustworthy. Research that produces numbers recruits hundreds, so this looks like it should too. But this method hunts for the places people get stuck, not for proportions. Among users who match the same conditions, the serious problems show up in the first three sessions, so inviting twenty people mostly means watching the same scene seventeen more times. Running five, fixing what you found, and running another five clears twice as many problems in the same stretch of calendar.

The second mistake is treating it as a final check before release. The word "test" makes it sound like a pass-or-fail gate applied to finished work. Used that way, a result that says the structure needs rethinking arrives when the schedule can't absorb it, and all you're left holding is a list of problems you can't fix. Run the same session on a clickable prototype and those problems get fixed in a day.