Guerrilla Test

Running a usability test properly takes time. Recruiting participants who match the criteria alone eats two weeks, and once incentives, scheduling, and a discussion guide are sorted, a month has passed before the first session. The results are worth it, but it's an expensive price to pay for fixing one screen.

So small decisions ended up being settled in meetings instead. Pagedeck did exactly that. When Noa put two versions of the invite screen side by side and asked which was better, Mia said the left one was clearer and Theo said the right one was more familiar. Both were arguing from personal experience, and the decision tilted toward whoever pushed harder. It wasn't a decision worth a month of research, but it wasn't one a meeting could settle either.

The guerrilla test fills that gap. It gives up accuracy in exchange for being extremely cheap. Nobody is recruited; you go where people already are. Coffee replaces the incentive. Each person gets five minutes. Two hours in an afternoon covers six people, and when four of the six stall in the same spot, there's nothing left to argue about in the meeting.

Five steps, sized so that setup through write-up fits in half a day.

1. Write down the one thing you want to know. "Evaluate the invite screen" is not a question. "Can someone who doesn't know a colleague's email address finish the invite?" is. It has to be answerable in five minutes, and two questions make both of them blurry.
2. Prepare what you'll show and what you'll ask for. A finished screen isn't required — a prototype is enough. Keep the tasks to one or two. "Invite one colleague from this screen" is about the right size.
3. Go where people are. Cafes, office lobbies, coworking spaces, and conference floors are the usual spots. Expect to ask several people for every one who agrees, so budget an afternoon for six sessions rather than an hour. Saying five minutes rather than shaving it down to "about a minute" leads to fewer people standing up halfway through, and naming the length honestly is also what keeps the session from turning into a rushed demo.
4. Give the task and watch. There's one rule to hold here: don't supply the answer. When someone's hand stops moving, the urge to point out that the button is at the top is strong, but that pause is exactly what you came for. Ask what they're looking for instead.
5. Write one line on the spot. After five people the sessions blur together, so note where each person stalled the moment they finish. Back at the desk, the only thing to count is how many of the six stalled in the same place.

Five or six people is enough. Four stalling at the same point is grounds for a fix; six stalling in six different places usually means the question was wrong, not the screen.

It fits screens anyone can judge without background knowledge — button labels on a signup screen, whether a landing page conveys what the service does, whether an explanatory line is actually read. A five-second test is short enough to stack onto the same session. Choosing between two versions, or checking a piece of copy found the week of launch, gets answered in half a day this way.

Where it doesn't fit is sharper.

1. Screens that need work context. Ask someone stopped in a cafe to change the company card on a billing settings screen and their stalling says nothing about the screen — they've never had to do that.
2. Problems that surface over time. Whether notifications get annoying in week two, or whether search still works once 200 documents have piled up, is invisible in five minutes. A first-time impression is the only thing a stranger can give you, which is also why the same person can't be used twice.
3. Decisions that need numbers. Four out of six is not a rate. Saying what percentage of users get stuck requires quantitative research, which works with dozens to hundreds of people.

The limit in one line: the participants are not your users. What comes out is a signal rather than a conclusion. Four people stalling in one place is grounds to fix that place, but nobody stalling is not evidence that nothing is wrong.

"Let's just do a guerrilla on this. Five people at the cafe this afternoon."

Don't schedule proper research — get an answer within half a day.

"We ran a guerrilla with six people and four stalled in the same place."

The sample is small, but it clustered, so treat it as grounds for a fix.

"You won't get that from a guerrilla test. Those aren't our users."

The screen needs work context, so strangers can't tell you anything about it.

At Pagedeck, Noa runs one at a nearby cafe whenever a screen changes substantially. After the invite screen was reworked, five of six people stopped at the email address field, and for the same reason: they don't have a colleague's work address memorized. What came out of it wasn't a request to make the screen prettier but to add a second path — a link to copy and send.

When Noa described that scene in the next day's meeting, the version debate didn't continue. Five people stalling in one place carried more weight than anyone's personal experience.

Carrying a six-person finding over as a statement about all users is common. Watching it happen in person makes it stick harder than any number would. But six people in a cafe were not selected against criteria; they were whoever was there at that hour. Turning that into "80 percent of users get stuck here" makes it false evidence, and priorities set from that sentence push genuinely urgent work backward. The honest version of the same finding is narrower and still useful: four of six people who had never seen the product stalled at this field.

The other frequent mistake is treating it as a cheap substitute for real research. It carries the usability test name, so it looks like a scaled-down version of one. What it yields is different. A moderated test spends an hour with someone who matches the criteria and gets at why they did what they did; this one grabs anyone at hand and sees only where they stall in five minutes. Teams that swap the first for the second keep fixing the obvious problems and never find the ones only their own users hit.