Not a replacement for proper research. Better than no research at all.

Guerrilla testing is a lightweight research method where designs or prototypes are tested quickly with readily available participants — colleagues from other teams, people in a coffee shop, friends — rather than recruited, scheduled participants. Sessions run 5-15 minutes, are informal, and require minimal setup.

The term reflects the improvised nature: you're not running a formal study, you're getting directional signal with whatever resources are at hand. It emerged from the lean UX tradition as a practical answer to the common situation of needing some user feedback when time and budget don't allow for anything more structured.

Guerrilla testing is the right call when:

• The team needs fast directional feedback — not a statistically significant finding, but a sense of whether the design is heading the right way
• Formal Usability Testing resources aren't available in the current cycle
• You're testing early concepts where rough feedback is more useful than none
• The design question is broad enough that almost any user population will surface the key problems

It's poorly suited for products with specialist user populations — clinical software, developer tools, niche B2B workflows — where non-target users won't have the mental models to test meaningfully.

Keep it short and focused:

1. A 30-second context-setting intro: what the product does, what you're testing. No more than that.
2. Two or three tasks to observe — things to do, not questions to answer.
3. A think-aloud prompt: ask participants to narrate what they're doing and why as they go.
4. Note-taking focused on moments of hesitation, wrong turns, and confusion.

Don't explain what the interface is supposed to do. That's the test. If users can't figure it out without a tutorial, the design has work to do. Five participants is typically enough to surface the most critical problems — the same issues tend to appear repeatedly once you've seen three or four sessions.

Guerrilla testing reliably surfaces usability problems severe enough to trip up almost anyone — confusing navigation, unclear labels, broken flows. These are worth finding before launch and are often found in the first session.

It won't tell you whether the design works specifically for your target user population, whether subtle problems affect experienced users differently from new ones, or whether the product is solving the right problem at all.

Treat guerrilla testing as a fast filter, not a research program. It finds obvious problems quickly. For deeper questions about whether the product is meeting real user needs, invest in Contextual Inquiry or formal usability testing with recruited participants.