Playtesting Methods for Indie Developers
Run a useful playtest this week with no budget, one friend, a short task list, and a notebook.
You do not need a lab, a survey platform, or a crowd of strangers to learn what is wrong with your game. You need someone playing it while you watch, and a plan for what to do with what you see.
This guide gives you a loop you can run in a few evenings. Test yourself first. Test one friend. Change one thing. Test again.
Decide what this test is for
Before anyone plays, write one question at the top of a page. Keep it narrow.
- “Can a new player finish the first level without help?”
- “Do players understand the dash move?”
- “Where does the second area feel slow?”
A test with one question gives you clear answers. A test with ten questions gives you a pile of opinions.
Pick the question that blocks you most right now. If you cannot ship without it, it goes first.
Play it yourself, on purpose
You have played your game hundreds of times. That makes you a poor tester, unless you change how you play.
Try this:
- Start from a clean save. Delete progress. Skip nothing.
- Play at normal speed. No debug keys, no level select, no cheats.
- Talk out loud or type as you go. Every time you think “that is a bit off,” write it down with a timestamp or a level name.
- Play badly once. Miss jumps. Ignore the main path. Go the wrong way. New players will.
Keep the notes plain. “Level 1, door: not clear it opens” beats “UX issues near start.”
Self-testing catches bugs, broken flow, and rough edges. It cannot tell you what a stranger understands. For that you need someone else.
Recruit one friend and set the rules
Pick someone who has not played your build. A friend, a sibling, someone from a local or online dev group. They do not need to be a gamer, though it helps if they play games like yours.
Set up a video call with screen sharing, or sit beside them. Then explain the rules before they start:
- They should think out loud. Say what they see, what they expect, what confuses them.
- You will not help. If they get stuck, that is useful information, not a failure.
- They can stop any time.
- There are no wrong answers. You are testing the game, not them.
Then follow your own rule: watch, do not help.
This is the hard part. You will want to explain the jump button. You will want to point at the door. Do not. Sit on your hands. Mute yourself if you must.
If they are stuck long enough that the session is going nowhere, give the smallest hint you can, and write down that you did. That moment is one of your most important findings.
Give a short task list
Open-ended play is good, but a few tasks make results easier to compare between testers. Write three to five, and keep them simple.
- “Start a new game and get to the first checkpoint.”
- “Find a way into the locked room.”
- “Try to beat the first enemy.”
- “Play until you feel like stopping.”
Do not explain how to do the tasks. The goal is to see whether the game teaches them.
The last task matters. Where someone chooses to stop tells you where interest drops. Note the moment and what was on screen.
Write down what they do, not what they say they think
During the session, keep a simple log. A paper notebook works. So does a plain text file.
Track these:
- Hesitations. Where did they pause, look around, or stop moving? Note the spot.
- Questions. Every question they ask out loud. “Is that a door?” “Can I climb this?” “What does the blue bar mean?” Each one is a gap in your design.
- Wrong guesses. What they tried that did not work. If three people try to jump on the same ledge, the ledge looks jumpable.
- Deaths and restarts. Where and why.
- Reactions. Laughs, sighs, leaning in, leaning back.
- Where they quit. If they stop before the tasks are done, where and when.
Use short codes to keep up. “H” for hesitation, “Q” for question, “D” for death. Add the level name or a rough location.
If your tester agrees, record the call. You can rewatch the parts you missed instead of trusting memory. Ask first, every time.
Ask a few questions after, not during
When they finish, ask three or four open questions. Keep them neutral.
- “What was the game about, in your own words?”
- “What was the most confusing moment?”
- “What did you want to do that you could not?”
- “Where would you have stopped if I were not here?”
Avoid “Did you like it?” Most friends will say yes. Avoid explaining your intentions. If you say “the bridge was supposed to be easy to spot,” they will agree it should have been, and you learn nothing.
Write their answers down word for word where you can. Their phrasing tells you how players will describe your game.
Sort your notes into one list
After the session, while it is fresh, go through your log. Group notes that point at the same problem.
Then sort the groups:
- Blockers. The player could not progress without help.
- Confusion. They progressed, but slowly or by accident.
- Friction. It worked, but felt clumsy.
- Polish. Small stuff that can wait.
Ignore suggested fixes for now. Players are good at spotting problems and less reliable at solving them. “Add a map” might mean “I got lost in the cave.” The problem is getting lost. A map is one possible fix.
Change one thing
Pick the top blocker. Change one thing to address it. Only one.
If players could not find the door, you might add light near it, or change its color, or move the camera. Choose one. Note what you changed and why.
One change at a time is slower, but it tells you what worked. If you change five things and the next tester finishes, you will not know which change did it.
Test again with someone new
Run the same task list with a different person. Same rules. Same notes.
Compare the two logs. Did the blocker go away? Did a new one appear in its place? Did the change cause a problem somewhere else?
Testers learn your game, so the same friend cannot give you first-impression feedback twice. Keep a short list of people who have not seen the build yet, and save them for moments when you need fresh eyes.
Make it a habit
Playtesting works best as a routine, not an event. A small test after every meaningful change catches problems while they are cheap to fix.
Keep every log in one folder with dates. Over time you will see patterns: the kinds of things players miss, the moments that land, the parts that drag.
Start this week. One self-test, one friend, one change. That is enough to make your game clearer than it was yesterday.
