Your friends will tell you your game is good. Other devs will tell you what they would have built instead. Neither of those is playtest feedback, and both of them will waste weeks of your development time if you treat them as data.
A useful playtest is a controlled situation where you learn something specific about how strangers behave in your game. Here is how to set one up.
Decide what you are testing before you invite anyone
“Come try my game” is not a playtest. It is a demo.
Before you schedule anything, write down one question you want answered. Examples:
- Can a new player get through the first five minutes without asking me anything?
- Do players understand that the blue meter is stamina?
- Is the third level too hard, or is the second level not teaching enough?
- Do players use the dodge, or do they tank hits and heal?
One question per session. If you try to test the tutorial, the combat balance, and the art direction at once, you will get vague impressions of all three and answers to none of them.
Who to test with
The biggest recruiting mistake is testing only with people who already like your genre. They will fill in gaps automatically because they have played forty games like yours. They will not notice that your controls are unexplained, because they already know the convention.
Mix your pool:
- Genre fans. Good for balance, depth, and whether your systems hold up.
- Genre-adjacent players. Good for onboarding and clarity.
- People who barely play games. Brutal and extremely useful for your first five minutes.
- Other developers. Useful, but hold their feedback separately. Devs critique implementation and pitch alternatives. That is a different signal than “I did not know where to go.”
Avoid testing repeatedly with the same handful of people. After the second session they know your game and stop being able to see it fresh.
For usability problems, five testers will surface the large majority of the issues. If four out of five people walk past the same door, the door is the problem, and testing fifteen more people will just confirm it more expensively.
Balance and difficulty tuning need more, because those depend on skill spread. Onboarding and clarity need very few.
Running the session
Say almost nothing
Hand them the controller or the keyboard. Tell them two things: think out loud if you can, and I am not going to help you. Then stop talking.
This is the hardest part and the part everyone fails. Watching someone struggle with something you built is physically uncomfortable, and the instinct to say “oh, you have to press X there” is nearly irresistible. Every time you give in, you delete the exact information you invited them over to produce. Your game will not have you sitting next to it on Steam.
Write down the moment you wanted to intervene. That moment is a bug in your design. Take notes on what they do, not how they seem to feel:
- Where did they pause?
- What did they try that did not work?
- What did they ignore entirely?
- What did they do repeatedly that you did not intend?
- Where did they die, and did they understand why?
- When did they check the menu, and what were they looking for?
Timestamps help. If you can record the screen, do it. Face cam is optional and mostly useful for spotting confusion versus frustration.
Thirty to forty-five minutes is plenty for most sessions. Past that, testers get tired and start being agreeable to end it faster.
Asking questions afterward, not during
Save your questions for the end, and ask about what happened rather than what they thought.
Bad questions:
- Did you like it?
- Was it fun?
- Would you buy this?
- Do you think I should add multiplayer?
These invite politeness, speculation, and design suggestions, in that order.
Better questions:
- What were you trying to do when you were stuck at the bridge?
- What did you think that item was going to do?
- How would you describe this game to a friend?
- What was the most frustrating part?
- If you stopped playing at some point, when and why?
“How would you describe this game to a friend” is worth asking every time. If their description does not match your pitch, your game is not communicating what you think it is.
Players identify problems well and solve them badly
Take this one seriously. A tester saying “the combat felt slow” is real information. That same tester saying “you should double the attack speed” is a guess.
Your job is to hear the complaint and diagnose the cause yourself. Slow combat might be attack speed, or it might be enemy health, hit feedback, wind-up animation, or the fact that the player never found the weapon upgrade. The fix is often nowhere near the thing they pointed at.
The same applies to feature requests. If three people ask for a minimap, the actual problem is usually that your levels are hard to navigate, and a minimap is the only solution they know how to name.
When to ignore feedback
Not all of it counts. Reasonable grounds for setting a piece of feedback aside:
- One person said it and nobody else did
- It came from someone outside your audience
- It contradicts the core thing your game is about
- It is a preference, not a problem
Log it anyway. If the same “one-off” shows up in three more sessions, it was never a one-off.
Remote playtesting
In-person is better for observation, but remote scales. Options:
- Steam Playtest. Built into Steamworks, ties to your store page, and testers already have Steam accounts.
- itch.io with a password-protected page. Fast and free.
- A Discord server with a testers channel. Good for ongoing feedback, and lets you ask follow-ups.
For remote, you lose the ability to watch. Compensate with a short structured form, in-game telemetry if you can manage it, or by asking testers to record their session.
Log everything and look for repeats
Keep one document per session with the date, tester, build version, and your raw notes. After three or four sessions, read them together and look only for repeats. Anything that shows up three times is a priority. Anything that shows up once goes in a backlog.
This is also how you avoid re-fixing things. Without a log, you will get the same feedback in month four that you already addressed in month two, panic, and change something that was fine.
Getting testers
If you do not have a pool yet, the fastest path is a local community. Bring a build to an SDC meetup or the Progressive Game Jam and trade sessions with other devs. Test each other’s games, take real notes, and swap. It costs you nothing but an evening, and it beats waiting for strangers on the internet to volunteer.
Convention floors work too, with one adjustment: shorten your build. A con demo has about ninety seconds to prove itself before someone drifts to the next booth.
None of this requires a finished game. The earlier you start watching people play, the cheaper your mistakes are. A rough build tested in month two saves you from shipping a tutorial that nobody understands in month twenty. Grab five people, keep your mouth shut, and take notes.