How to playtest your indie game
How to playtest an indie game from scratch: what to prepare, how to run the session, and how to read the results without fooling yourself.
To playtest an indie game you need four things: one specific question you want answered, a slice of the game that survives fifteen minutes unattended, five to ten people who have never seen it, and a consistent way to capture what they did and said. You do not need a lab, a publisher, or a budget. Almost everything that makes a playtest useful happens before anyone presses play, in the choice of what you are testing and what you refuse to explain.
I have run these badly for years, so most of this guide is written from the wrong side. Here is the version I wish someone had handed me.
What counts as a playtest, and what does not
Sitting next to a friend on your own laptop while you narrate the controls is a demo. It feels great and teaches you nothing, because you removed the exact obstacle you were supposed to be measuring.
Three things turn a demo into a playtest:
- A question. You are testing something specific, not "the game."
- Silence. You do not explain the controls, the goal, or the UI. If a player needs the explanation, that is the finding. Write it down instead of saying it.
- A consistent record. Every tester answers the same questions in the same order, so answer number seven means something next to answer number two.
Anything that keeps those three intact is a valid playtest, including a Discord friend playing a browser build at midnight in another timezone.
What do you need before your first playtest?
One question, written down
"Is my game fun?" is not a question, it is a mood. Testable questions look like this:
- Do players understand what to do in the first sixty seconds without being told?
- Does anyone find the dash ability before the second room?
- Do players read the shop UI as a shop, or as a menu?
- Where do people quit when nothing forces them to keep going?
Pick one. You can collect side observations, but the whole session is designed around answering that single question, and every survey question you write either serves it or gets cut.
A slice, not the whole game
Fifteen to twenty minutes is the realistic ceiling for an unpaid tester playing an unfinished game. Choose the slice that actually contains your question. If the question is about onboarding, the slice is the first level and nothing else. Ship the rest later.
A build strangers can start
If the tester has to download a zip, unblock a binary, and read a README before playing, you will lose a good chunk of them at each step, and the ones who survive are your most forgiving fans. That is the worst sample you could pick. Browser builds, itch.io pages, or a hosted WebGL slice remove most of that loss for free.
Testers who have never seen it
Fresh eyes are the entire product. A person who watched your last four devlogs cannot un-know the map. If you are short on strangers, here is where I go to find playtesters.
How to run your first playtest, step by step
- Write your question at the top of a doc. Everything below has to serve it.
- Cut the build to the slice that answers it. Disable anything that could crash outside that slice.
- Write a three-question pre-survey. Experience with the genre, platform they are playing on, and what they expect from the game based on the title or capsule art. That last one is quietly the most useful question in playtesting.
- Write a post-survey of five to eight questions. Mix a rating, a couple of specific multiple-choice questions tied to your one question, and one open text prompt. There is a full copy-paste bank in playtest survey questions that get real answers.
- Set a session length and say it up front. "About fifteen minutes" respects people's time and raises completion.
- Send it to five to ten people in the first round. Not fifty. You will change the build after the first three anyway.
- Watch or read the first two sessions before the rest come in. If both testers hit the same wall in minute one, stop, fix it, and let the remaining testers reach new ground instead of re-confirming a bug you already know about.
- Sit on the results for a day before you change anything. The urge to patch the loudest complaint at 1am is strong and usually wrong.
What should you actually measure?
Opinions are the cheapest data in a playtest and the least reliable. Weight behaviour higher than commentary, and collect both.
| Signal | How to capture it | What it tells you |
|---|---|---|
| Completion rate | Sessions that reach the post-survey vs sessions started | Whether the slice holds attention at all |
| Where sessions end | Timestamp or last event before drop-off | Your real difficulty or boredom wall |
| Time to first meaningful action | An in-game event when the player first does the core verb | How long onboarding actually takes, not how long you think it takes |
| Confusion in the moment | A question triggered in-game, or a screen recording | The thing testers forget by the time they reach the post-survey |
| Post-session rating | A 1 to 5 rating question | A blunt trend line across builds, useful only when compared to itself |
| One open text answer | "What is the first thing you would change?" | The problems you did not think to ask about |
The single most common gap is the fourth row. A player gets confused in minute three, muddles through, and by minute fifteen writes "it was pretty good" because the frustration has already faded. Catching that moment while it is happening is worth more than any post-session essay, which is why PlayProbe can fire a survey question mid-game when a Unity event fires, and why screen recordings exist for everything else.
How do you read playtest results without fooling yourself?
Count what people did before you read what they wrote
If six of eight testers never opened the crafting menu, the fact that two of them called crafting "fun" does not matter yet. Discoverability failed first.
Look for the repeated complaint, not the loudest one
One furious paragraph about your camera is one data point. Four people mildly mentioning that they lost track of the objective is a design problem. Volume of feeling is not volume of evidence.
Fix the problem, not the suggested solution
Players are excellent at reporting where it hurts and unreliable at prescribing cures. "Add a minimap" usually means "I got lost." A minimap is one of maybe five valid answers to that, and often the laziest.
Separate a bug report from a design signal
Crashes and softlocks are QA findings, and you fix them without debate. "I did not understand why I lost" is a design finding, and it needs a design decision. Mixing the two lists is how a bug tracker eats a design review. I go into where the boundary sits in how many playtesters do you need.
How often should you playtest?
More often than feels comfortable, with fewer people each time. A round of five testers every two weeks will teach you more than a round of forty once a quarter, because the small rounds actually change the build, and the change is the point.
A cadence that works well for a small team:
- Every build with a new mechanic: three to five testers, one question, unlisted link.
- Every milestone: eight to fifteen testers, wider question set, recordings on.
- Before a demo or festival submission: a fresh group who have never touched any earlier build.
Mistakes I keep seeing in first playtests
- Testing the whole game instead of a slice, so nobody finishes and every result is about fatigue.
- Explaining the controls in the Discord message, then wondering why nobody reported a control problem.
- Asking "did you like it?" which reliably produces "yeah, it's cool" from people who do not want to hurt you.
- Only inviting people from your own community, who already like the genre, the art, and you.
- Collecting great feedback and then not shipping a build that responds to it, which quietly teaches your testers that answering was pointless.
Where PlayProbe fits
This is the tool I built because my own process kept falling apart at step six. With PlayProbe you set up a pre-survey, point at a WebGL embed or your itch.io page, add a post-survey, and share one link. Testers play in the browser with no account and no download, and the answers land aggregated in a dashboard instead of scattered across DMs and a spreadsheet. On Unity you can go further and ask questions during play, the moment something happens.
The free plan covers one game, three tests, and twenty sessions per test, which is enough to run your first few rounds properly. If you want to see what real playtests look like from the tester side, the open playtests page lists indie games currently looking for players.
Whatever you use, the process matters more than the tooling. One question, a short slice, fresh players, silence, and a build that changes afterwards.