How Many Playtesters Do I Need? Numbers by Goal

How many playtesters do I need? It is one of the first questions every indie developer asks, and the honest answer is that the right number depends on what you want to learn, not on the size of your game. Five people can tell you your tutorial is broken. Five people cannot tell you whether your second boss is too hard for most players. This guide gives you a number for each kind of question, explains where those numbers come from, and shows you how to plan rounds so a small team can test often without burning through every fresh player it can find.

The short answer

If you only read one section, read this one. These are starting points per round, per type of player:

• Finding problems (confusing tutorial, unclear UI, missed objectives, softlocks): 5 to 6 players. Fix what they find, then test again with new people.
• Understanding your players (why they play, what they compare your game to, who your audience is): around 12 players, then keep going only if you are still hearing new things.
• Measuring something (ratings, preference between two versions, percentage who finish a level): around 100 survey responses for a practical result.
• Multiplayer: at least one full lobby per session, and enough sessions to repeat the problem.
• Bugs and hardware coverage: as many as you can get. This is QA, and volume is the point.

Then add a buffer for no-shows. Recruit one or two more than you need for every small round.

Where the "five players" number comes from

Most advice about playtest numbers traces back to one article: Jakob Nielsen's "Why You Only Need to Test with 5 Users" at Nielsen Norman Group. Nielsen and Tom Landauer looked at usability studies and found that a single test user, on average, reveals about 31% of the usability problems in a design. Each extra user overlaps more and more with what you have already seen. By around five users you have found most of the problems you are going to find in that round, and after that you are mostly watching people trip over the same things.

The important part, and the part people skip, is what Nielsen recommends doing with the rest of your budget. If you could afford 15 users, he says, run three studies of five instead of one study of 15. The first round finds the big problems. You fix them. The second round checks whether your fixes actually worked, catches problems the first round missed, and finally lets you see deeper issues that were hidden behind the obvious ones.

That logic carries over to games well. Paul Sztajer made the same point on Game Developer back in 2011: three to five players per iteration is enough for early playtesting, as long as you actually plan the session and observe players rather than just sending a build to friends and asking what they think.

Why games are not websites

Steve Bromley of Games User Research warns that the five-user rule is widely cited and often applied incorrectly. Games are more complex than the websites Nielsen studied, and the rule only covers one kind of question: finding problems. It says nothing about whether players like your game, whether the difficulty curve is right, or which of two designs is better.

So before you pick a number, decide which kind of question you are asking.

Pick your number by the question you are asking

Finding problems: 5 to 6 per round

This covers most indie playtests. Can players work out the controls? Do they find the first objective? Do they understand the upgrade screen? Is there anywhere they get stuck?

Bromley recommends six players for this kind of playtest, then stopping to reflect. Why six instead of five? Because someone will not turn up, and with one no-show you still have five.

Signs you have enough for this round:

• The last two players hit the same problems as the first three or four
• You already have a list of fixes you are confident about
• You are starting to predict what the next player will do

When you see those signs, stop. Fix things. Recruit new people for the next round.

Understanding your players: around 12

If you want to know who your players are, what they enjoy, what other games they compare yours to, or how they would describe your game to a friend, you need more people. Bromley suggests starting with 12 per type of player, then looking back at what you've learned before deciding whether to talk to more. You are aiming for saturation, the point where new players mostly repeat what earlier ones said.

This is the round to run before you write your store page or pitch. The words players use to describe your game are often better than the ones you would write yourself.

Measuring things: around 100

Some questions need numbers. How do players rate the combat out of 5? What share prefer version A over version B? How many players finish the first chapter?

For a survey, Bromley explains the margin of error: around 400 responses gets you to roughly a 5% margin, but that is impractical for most teams. He suggests 100 responses as a practical number, which gives roughly a 10% margin of error. That is good enough for most game design decisions. It is not good enough for splitting hairs, so don't treat a 52% versus 48% result as a clear winner.

Measurement questions also usually need telemetry, not just opinions. If you want to know where players quit, log where they quit.

Balance and difficulty: more players, longer sessions

Difficulty is personal. One player's fair challenge is another's wall. You need a spread of skill levels, and you need people to play long enough to reach the parts you are tuning. For balance and progression, plan for more players than a problem-finding round, and plan for longer or repeated sessions. Combine what they say with data like deaths, retries and time spent per level.

Adjust for your game and your players

More than one type of player

The numbers above are per type of player. If your game needs to work for genre veterans and complete newcomers, test both groups, because they fail in different places.

Nielsen's guidance for multiple groups:

• Two groups: 3 to 4 players from each
• Three or more groups: 3 from each, because you always want at least three to see the range of behaviour within a group

Bromley gives a simpler rule for problem-finding: six per type of player. If you're testing kids and adults, that's six of each.

Common player types worth separating in indie games:

• Genre veterans and genre newcomers
• Keyboard and mouse players and controller players
• Players on high-end PCs and players on laptops or handhelds
• Solo players and groups, for co-op games

You don't need all of these every round. Pick the split that matters for the question you are asking.

Multiplayer games

As Bromley points out, if you are testing a 4v4 game you need eight people just to start. Multiplayer changes the math:

1. Count lobbies, not players. One session needs a full lobby. If your game is four player co-op, a round of three sessions needs twelve people.
2. Recruit extra. One missing player can cancel a whole session. Over-recruit by at least one per lobby.
3. Test solo first where you can. Sztajer describes having players do a single-player session before playing together, so the multiplayer test focuses on interaction rather than learning the controls.
4. Use bots or devs to fill gaps only for testing systems like matchmaking or netcode, not for testing how real players interact.

Mobile games on Google Play

If you have a personal Google Play developer account created after November 13, 2023, there is a separate, non-negotiable number. Google's Play Console Help says you must run a closed test with at least 12 testers who have been opted in continuously for at least 14 days before you can apply for production access. When you apply, you also have to summarize the feedback you got and describe what you changed because of it.

That means 12 is a floor, not a target. Recruit more than 12 so a few dropouts do not reset your clock, and run a real feedback round alongside the closed test so you have something useful to write in the application.

Demos and festivals

Before a demo goes public, for example ahead of Steam Next Fest, you want fresh players who have never seen any earlier build. Run one more problem-finding round of five or six cold players on the exact build you will release. If you are preparing for a fest right now, the Next Fest demo feedback guide covers that plan step by step.

How many rounds do you need?

The number per round matters less than running enough rounds. The Games User Research 2023 Playtest Survey found that most teams run between two and five external playtests a year, and that teams often get more value from many small studies than one big "perfect" playtest.

For an indie game, a realistic rhythm looks like this:

• Prototype: a round of 3 to 5 players whenever the core loop changes. Other developers are fine here.
• Vertical slice to alpha: a round of 5 to 6 players who match your target audience every few weeks, with fixes in between.
• Before a demo or launch: one or two rounds of cold players on the near-final build, plus a survey round of around 100 if you need to measure appeal.
• Beta: as many players as you can get for bugs and hardware coverage, alongside smaller focused rounds for anything you changed.

The golden rule: every round should use new players for the thing you are testing. Someone who already learned your controls cannot tell you whether the tutorial teaches them.

A planning template for your next round

Copy this into your notes before you recruit anyone:

1. The question: what decision will this round help you make? Write one sentence.
2. The question type: finding problems, understanding players, or measuring.
3. Player types: which groups need to be represented, and how many from each.
4. The number: use the guide above, then add one or two for no-shows.
5. The build: which version, and what you want each player to reach.
6. The method: watching live, recorded sessions, or a survey.
7. Stop rule: what will tell you this round is done (repeated problems, or a target number of survey responses).
8. Next round: when you'll test again, with new players.

Example for a small roguelite:

• Question: do new players understand the upgrade shop on their first run?
• Type: finding problems
• Player types: roguelite fans and players new to the genre
• Number: 6 of each, recruit 7 of each
• Build: demo v0.6, play until the second shop
• Method: recorded sessions, players talking out loud, three questions at the end
• Stop rule: if the first 4 of a group all miss the same thing, fix it before the rest
• Next round: two weeks later on v0.7, new players

For the questions to ask at the end of a session, the playtest survey questions guide has a bank organized by goal.

What if you can't reach these numbers?

Then test with whoever you can get. Bromley is clear on this: one player is infinitely more than none, and if you can only get two or three people, still run the playtest. Most teams in the Games User Research survey were working with small samples too: almost half reported running playtests with ten or fewer players.

A few ways to make small numbers count:

• Watch rather than ask. One recorded session tells you more than five "yeah, it's fun" messages.
• Narrow the question. Three players can answer "do people find the door?" They cannot answer "is the game fun?"
• Test more often. Three rounds of two players, with fixes between them, beat one round of six that you never follow up.
• Get fresh eyes from outside your circle. Friends and teammates are not cold players.

Finding the people is usually the hard part. The how to find playtesters guide covers the channels that reliably work. You can also post your game on Get Playtests for free, with no credit card and no identity check. Players pick games they want to play and send written, video or livestream reviews, and video reviews in particular give you the watch-them-play footage that small rounds depend on. If you are new, your first posting may wait until a review you write for another developer's game is approved, which is how the site keeps reviews coming for every game. If you work with an AI assistant, you can even post playtests from it.

Quick reference

• Finding problems: 5 to 6 per round per player type, then fix and repeat
• Understanding players: about 12 per player type, more until you hear repeats
• Survey measurement: about 100 responses for a practical result
• Multiplayer: full lobbies, plus spares
• Google Play closed test: at least 12 testers opted in for 14 continuous days, recruit more
• Always add one or two for no-shows
• New players every round for the thing you are testing