Guerrilla testing: fast, cheap research in public places
Guerrilla testing runs short sessions with people in public spaces for quick feedback. How to prepare, how many to run, and why it is not a formal test.
What is it and why does it exist?
The idea is simple: instead of waiting to recruit participants through a vendor, you find people where they already are. A café, a library, a coworking space or a busy street. Adobe XD describes it as a relatively fast and informal way to test ideas and get high-level feedback.
Its value lies in speed and cost. According to Lyssna, it is a quick and inexpensive way to gather user feedback by testing with people in informal settings. The name reflects the improvised nature of the method, in contrast with a usability lab planned weeks in advance.
How do you prepare it?
Although it is informal, treat it as a serious test. The guides consulted point to three preparations:
- A clear goal. A single question the result must answer, for example “do people find the price without help?”
- Two or three simple tasks. Lyssna recommends two to three key tasks, and Maze asks for a short list centered on one core user objective.
- Materials ready. A realistic, working prototype (Maze advises against paper), with the tasks printed or on a phone, and something to offer in return, such as a coffee and a cake, which Adobe XD mentions as an incentive.
Before going out, run the session with someone on your team. A small pilot catches confusing instructions and unclear tasks. If you are unsure whether to sit with the person or leave them alone, see moderated vs. unmoderated testing.
How do you run the session?
A common sequence is this: ask the person for a few minutes, give them the tasks, observe without intervening more than necessary and finish with questions about their experience. Maze suggests asking people to think aloud while they use the prototype and saving open-ended questions for the end. If you will record audio or screen, ask permission first. A support person taking notes lets you focus on observing.
Observation counts more than answers. If someone stays still in front of a button, that is data, even if they do not say so. Note what the person does, not only what they say, and record the context: noise, distractions, whether they were in a hurry.
After several sessions, look for patterns: review all the observations together and turn what repeats into concrete design changes, rather than treating each isolated comment as the truth. Lyssna suggests continuing until new participants stop revealing new problems.
How many people do you need?
The guides do not agree on the figure. Adobe XD recommends 8 to 10 people, with diversity of age, culture and gender, and Lyssna 5 to 8; Maze gives no number. The difference makes sense: the number depends on the question, on how varied your audience is and on how much time you have. What matters more than the number is that the people resemble your audience.
That is the method’s main risk. The people you meet in a café are not necessarily your customers. Maze names it as the main limitation: if participants do not represent your audience, results are less reliable. Adobe XD and Lyssna warn about the same thing. That is why screening questions before the test are worth asking, such as how often people shop online or whether they use similar apps, which is the example Maze gives.
What can it not do?
The guides consulted agree that guerrilla testing does not replace formal research. Adobe XD says it should not replace formal user testing, that sessions cover only a small part of the flow and that findings are not thorough, so big decisions call for caution. Lyssna adds that it is great for finding problems, but that formal methods help you understand them. Maze places it in the formative phase, early in design, and recommends moving to summative testing with a larger, more standardized sample when you need finer feedback.
There are practical limits too. Lyssna notes that public environments can be noisy or distracting; sessions are short and do not allow complex behaviour to be explored. Adobe XD adds that informal data can make stakeholders harder to convince. Nor is it suitable for sensitive content or for people with specific needs that a random sample will not include. For those cases, formal usability testing remains the option.
Example
Illustrative example: a team designing the payment flow of a food-delivery app wants to know whether people understand the delivery options before starting a full redesign. It takes a prototype to a café near an office district, one afternoon. Before each test, it asks whether the person orders delivery at least once a month; if not, it thanks them and looks for someone else. It runs eight sessions of seven minutes with two tasks. Five people cannot tell “scheduled delivery” from “fast delivery”. The team changes the wording and hierarchy of those options, then runs a formal test with recruited users to confirm the change.
For your next week: define one question, write two tasks and test with two colleagues. If the instructions are clear to them, they are probably clear to someone who stops on the street.
When should you NOT use it?
- When you need statistical data or comparisons between groups.
- When the product is sensitive, such as health or finance, and you cannot guarantee privacy in a public space.
- When the audience is very specific and does not appear in one particular place.
- When the decision is big and getting it wrong is costly. A guerrilla finding is a lead, not a proof.
Common mistakes
- Calling it formal research and deciding on its basis without confirming.
- Recruiting anyone without screening questions.
- Long sessions that tire the people who stopped by.
- Giving tasks with the steps included.
- Taking one isolated comment as a pattern.
- Not recording the context: place, time and noise, which explain part of what is observed.