How to Run a Playtest With Ten People and Learn Something Real

Ten people will surface nearly every usability and comprehension problem in a game, provided you watch them play in silence and ask questions afterwards rather than during. The value comes from observing behaviour, not from collecting opinions. Opinions are what testers offer when nobody is watching what they did.

Why this matters

Playtesting is the cheapest information available in game development and the most commonly skipped.

Teams skip it because it feels like it needs infrastructure. It does not. Ten sessions of twenty minutes, run properly, will change your build more than a month of internal discussion.

The reason it works is that you cannot un-know your own game. Everyone on the team has lost the ability to see it fresh, and testers have not.

You are not testing whether people like the game. You are testing whether they can play it.

Why ten is enough

For finding problems rather than measuring preferences, small numbers work well.

The pattern is consistent: the first few testers surface the majority of issues, and by around ten you are mostly seeing repeats. Problems that only one person in ten hits are usually genuine but lower priority.

Ten is not enough to answer questions about preference, balance, or whether one variant outperforms another. Those need traffic and measurement rather than observation.

Match the method to the question. Comprehension, usability, and difficulty read well with ten. Anything comparative does not.

Recruiting people who are not your friends

The recruiting mistake determines the quality of everything afterwards.

Friends, family, and colleagues are all compromised in the same way: they want you to succeed, and it makes them generous.

Better sources:

• Friends of friends, one step removed, who feel less obligation.
• People in the game's actual audience, found in communities where they already are.
• Small paid recruitment, which is inexpensive at this scale and buys honesty.
• Public places, if your game is quick. Ten minutes and a coffee gets you a session.

Two rules regardless of source. Recruit people who play the kind of game you are making, and never test with the same person twice for comprehension questions. Once they know the game, they cannot tell you whether it is understandable.

What to ask, and what never to ask

Ask almost nothing during play. Afterwards, ask open questions.

Good questions:

1. What were you trying to do there? Asked about a specific moment you observed.
2. What did you expect to happen when you did that?
3. Tell me what the game is about, asked after the session, in their own words.
4. What was the most annoying part? People answer this more honestly than its positive counterpart.
5. Would you open this again tomorrow, and why?

Questions to avoid:

• "Do you like it?" Invites politeness and produces nothing actionable.
• "Would you pay for this?" People are unreliable predictors of their own spending.
• "Should I add X?" Testers are not designers, and they will say yes.
• Anything leading: "was that part fun?" answers itself.

Never explain the game before they play. The explanation is the thing you are testing.

Watching instead of listening

What people do is reliable. What they say about what they did is not.

Watch four things specifically.

That last one is the most useful signal in the session. Write down every question asked, because each one is a specific comprehension failure with a location.

Record the screen with touch indicators where you can, and stay quiet. Silence is uncomfortable and it is the technique.

The specific opening to watch hardest is covered in Why Most Prototypes Fail in the First Ten Seconds.

Running the session

A twenty-minute structure that works.

1. Two minutes of setup. Explain that you are testing the game, not them, and that you will be quiet.
2. Ten minutes of silent play. No help, no matter how uncomfortable. If they are stuck, that is the finding.
3. Five minutes of questions, using the list above, anchored to moments you saw.
4. Three minutes of open conversation, where the most useful unprompted comments usually arrive.

Take timestamped notes rather than writing prose. "0:40 tapped background twice" is worth more than a paragraph of impression.

Turning notes into a change list

Ten sessions produce a lot of notes and the temptation is to act on all of them.

Work through it in three passes.

Pass one: count. Group observations by what happened, and count how many testers hit each. Frequency is your priority signal.

Pass two: separate observation from suggestion. Testers offer solutions constantly. Keep the problem, discard the proposed fix, and design your own.

Pass three: decide. For anything three or more testers hit, either fix it or write down why you are not. The written reason matters, because the same issue will resurface next round.

Then test the fixes with new people. A fix verified with the same testers proves nothing, since they have already learned the game.

What we would do

Run five sessions, make changes, then run five more. Two rounds of five beats one round of ten, because the second round tests your fixes rather than repeating the same findings.

Record the sessions and make the team watch one. A designer watching somebody fail to understand their own screen changes more minds than any written report.

Then keep a running list of every question a tester asked. Over several rounds it becomes an accurate map of what your game fails to communicate.

The short version

• Ten testers find nearly every comprehension and usability problem.
• Recruit outside your circle, from people who play this kind of game.
• Never explain the game first; the explanation is what you are testing.
• Stay silent during play, and ask open questions afterwards.
• Watch hesitation, repeated failures, and every question asked.
• Prioritise by how many testers hit an issue, and keep problems rather than suggested fixes.

Run five sessions this week with people you do not know. If you want an outside team to run and report on them, get in touch.

Related reading: How Playtesting Works and Why It Saves Money, Stop Polishing, and What Happens in the First 30 Seconds.