How to Run a Playtest: A Session Script for Indie Games

Knowing how to run a playtest is mostly knowing when to stay quiet. Most indie developers get the recruiting done, sit someone down with the build, and then ruin the session in the first five minutes by explaining the controls, pointing at the door the player missed, or defending the jump height. This guide gives you a full session script for a video game playtest: what to prepare, what to say word for word, what to watch, the neutral prompts to use when the player goes quiet, the debrief, and how to turn a pile of notes into the next build. It works for a friend on your couch, a stranger at a meetup, or a call over Discord.

Start with one decision, not a session

Before you book anyone, finish this sentence: "After this round, I will decide whether to ___." Keep the old tutorial or replace it. Ship the second biome in the demo or cut it. Make the first boss easier or leave it.

That one decision tells you who to recruit, where the player should start, when the session ends, and what to write down. A playtest without one turns into "so, what did you think?", and the answer to that is always "yeah, it's fun".

Write three things on the top of your notes sheet:

• The decision this round informs.
• The question you need answered to make it, phrased as something you can observe. "Can a new player finish the first delivery without help?" beats "Is the tutorial good?"
• What success looks like. "Reaches the cabin in under five minutes without asking where to go." Your own threshold, not a universal number.

If you need help turning goals into questions, our playtest survey questions guide starts with exactly that step.

Choose the format

There are four common ways to run a video game playtest. Pick the one that fits your question.

• In person, one player, you watching. The richest data. Best for onboarding, controls and "where do people get lost". If the opening is your main worry, our game onboarding playtest guide covers what to log in the first 10 minutes. This is what the script below is built around.
• Live call, one player. Screen share on Discord or Zoom, camera on if they are happy to. Nearly as good as in person, and your testers can be anywhere.
• Recorded or async. The player records themselves playing and talking, then sends the video. You lose the chance to ask "why?" in the moment, but you can run many at once and watch at double speed.
• Several players at once. A room or a scheduled multiplayer session, with you taking notes and a short survey at the end. Best for multiplayer balance and server load, worse for understanding individual confusion.

Whichever you pick, the rules for not leading the player are the same.

Prepare the build and the setup

Most ruined sessions are ruined before the player arrives. Run this checklist the day before:

1. Play the exact build you will test, from a fresh install, start to the planned end point. Not the build from yesterday.
2. Set the starting point. A save file or debug jump to the section you care about saves ten minutes of menus.
3. Turn off your dev shortcuts. Debug overlays, god mode keys and console commands that a real player would never have.
4. Use the player's kind of hardware. If your audience plays on a controller or a Steam Deck, test on one.
5. Decide what you are recording (screen, voice, face) and ask permission before you hit record. Explain what you will do with the recording and that they can say no.
6. Print or open your notes sheet (template below) and your script.
7. Recruit a note taker if you can. Games User Research makes the point that accurate note taking while also moderating is very hard. If you are alone, record the session and take light notes with timestamps.
8. Set your rescue rule. The one situation where you will step in, usually a known bug that blocks progress and that the player has no way to work around.

The session script, minute by minute

This is a 40 minute one-to-one session. For a quick first-impressions test, shrink the play section and keep everything else.

0:00 to 0:05: Welcome and brief

Read this out, close to word for word. Reading it stops you from improvising an explanation of your game.

Thanks for doing this. I'm testing the game, not you, so there is nothing you can do wrong. If something is confusing or annoying, that's exactly what I need to find. Please play like you would at home. While you play, try to say what you're thinking out loud: what you're looking at, what you're trying to do, what you expect to happen. It feels weird at first. If you go quiet I'll give you a nudge. I'm going to try not to help or answer questions while you play, because I need to see what a player does without me there. That's not me being rude. Ask anyway, though, because your questions tell me a lot. We'll talk properly at the end. You can stop any time. Any questions before we start?

If you are recording, confirm consent again here.

If they do not know you made the game, do not tell them yet. If they do know, say it plainly and add that honest, even harsh, feedback is the most useful thing they can give you.

0:05 to 0:30: Play, and you stay quiet

Give a task that does not reveal the answer. Games User Research gives a good example: "Use the pause menu to upgrade your jetpack" tells the player where the upgrade lives, so you will never find out whether they could find it. "Upgrade your jetpack, and tell me when you think you've done it" does not.

Then watch. Your job for the next 25 minutes is to notice and write, not to talk.

0:30 to 0:38: Debrief

Ask about specific moments you saw, in the order they happened. The debrief section below has the questions.

0:38 to 0:40: Close

Thank them. Tell them what happens next with their feedback, and ask if they would play the next build. Knowing their notes will shape the next build gives them a reason to come back.

During play: what to watch and when to speak

Jakob Nielsen's summary of a think-aloud test fits on a sticky note: recruit representative users, give them representative tasks, and shut up and let the users do the talking. For games, add "and watch their hands".

What to write down

For every useful moment, log four things:

• Time (or route step), so you can find it in the recording.
• What they did. "Walked past the glowing chest twice."
• What they said, kept separate from what they did. Players often say one thing and do another.
• What happened next. Games User Research stresses this: a player who is lost for 15 seconds and recovers is a different problem from one who is lost for 20 minutes. The recovery is how you rank issues later.

The behaviours that usually matter most:

• Long pauses, especially with the mouse or stick not moving.
• Backtracking, or circling the same area.
• Pressing a button that does nothing. One r/gamedev commenter described a test where players kept hitting Escape to cancel an action that had its own cancel key. The fix was to make Escape work too.
• Reading something aloud and getting it wrong.
• Leaning in, laughing, swearing, sighing, or reaching for their phone.
• Skipping text, tutorials or cutscenes.

Neutral prompts for when they go quiet

Keep a short list of bland questions that keep the player talking without giving anything away. These come from Games User Research and work in almost every situation:

• "What are you up to right now?"
• "What are you thinking here?"
• "What's your goal?"
• "How did you know you had to do that?"

When the player asks you something, answer with a question. "What am I supposed to do here?" becomes "What do you think you're supposed to do?" Meta's VR playtesting guide recommends exactly this habit, along with getting comfortable with long pauses.

When to step in

Only when your rescue rule is met, or when the player is genuinely upset or asks to stop. If you do help, note the exact moment and what you said, and treat anything after it as contaminated for that issue. Nielsen warns that prompts from an untrained facilitator can easily change what the player does, so the next best thing to not biasing them is knowing when you did.

Things that feel helpful but wreck the data:

• Explaining a mechanic before they find it.
• "Oh, that's a known bug" (now they stop trying things).
• Laughing along at your own joke before they react.
• Defending a design choice. Write the complaint down and say "thanks, that's useful."

The debrief: ask about moments, not opinions

The debrief is where you find out why. Walk back through what you saw, oldest moment first, and keep every question about something that actually happened.

• "Early on you stopped at the bridge for a while. What was going through your head?"
• "When the door didn't open, what did you expect to happen?"
• "What did you think the goal of that level was?"
• "Was there a moment you felt stuck? What happened?"
• "Which part would you skip if you played again? Which part would you replay?"
• "If you were telling a friend about this, how would you describe it?"
• "Anything you wanted to do that the game didn't let you?"

Avoid questions that suggest an answer ("Was the jump too floaty?") and avoid asking them to design for you ("How would you fix the camera?"). What players struggled with is reliable. Their proposed fixes are much less so.

If you want written answers too, send a short form right after the call while it is fresh. Our game feedback form template is built for exactly that, with the build version filled in automatically.

Copy-paste notes sheet

Use one per session. Keep player contact details off the shared copy.

• Round: decision this informs, question, success criteria
• Build: version, starting point, planned end point
• Player code: P01 (no names), relevant experience (genre, platform)
• Consent: recording yes or no
• Observations: time, did, said, what happened next, did I intervene
• Debrief answers: short quotes, attributed to the moment they refer to
• Top three issues from this session: one line each
• Did they reach the success criteria? yes, no, with help

When you can't be in the room

You do not always get to sit next to someone. Async playtests work well if you set them up properly:

• Ask for a think-aloud recording, not just a video. A silent gameplay capture shows you what happened but not what the player expected.
• Give the same brief in writing. Paste your welcome script into the invite: you are testing the game, play like you would at home, say what you think.
• Name two or three focus areas. "The first 15 minutes, the crafting menu, and whether you'd keep playing" gets far better answers than "any feedback welcome".
• Watch every recording with your notes sheet open and log it exactly like a live session.

Finding strangers who will actually do this is the hard part. On Get Playtests, you post your build link with the focus areas you want covered, and players who chose your game send back written, video or livestream reviews. It is free to post, with no credit card. Video reviews are the closest thing to sitting behind a stranger while they play. For more places to recruit, see how to find playtesters.

After the session: from notes to the next build

Do this within a day, while you still remember the faces.

1. List every issue from every session in one place, one line each, with the player codes who hit it.
2. Merge duplicates. "Couldn't find the map key" from three players is one issue seen three times.
3. Rank by how many hit it and how bad it was. The recovery notes do the work here: blocked for minutes beats a two-second hesitation.
4. Separate behaviour from opinion. "Four of five missed the dodge" is a fix. "One player didn't like pixel art" is a data point.
5. Pick the smallest change that might fix each top issue, and write how you will check it worked.
6. Retest with new players. People who already know the answer cannot tell you whether the fix worked. If you are unsure how many to bring in, how many playtesters you need has numbers by goal.

Then go back to your decision from the start of this guide and make it. That is the point of the whole round. To write the round up in a form you can reuse, our playtest report template gives every finding a severity, a count and a decision. If the round left you wondering whether the core idea works at all, how to know if your game is fun covers the signals to watch across sessions.

Mistakes that ruin a playtest

• Testing a build you have not played from a clean install.
• Explaining the game before they press start.
• Answering "what do I do here?" with the answer.
• Asking "did you have fun?" and treating "yes" as a result.
• Testing only with friends who know your design.
• Taking notes on opinions and none on behaviour.
• Running ten sessions on the same build without fixing anything between rounds.
• Getting defensive. The moment you argue, the player stops being honest.

Quick checklist

• One decision and one observable question for this round.
• Fresh install of the exact build, dev shortcuts off.
• Recording consent asked before recording.
• Welcome script read out, including "I'm testing the game, not you".
• Tasks that do not give away the answer.
• Quiet during play; neutral prompts only; answer questions with questions.
• Log time, did, said, and what happened next.
• Debrief about specific moments.
• Issue list, ranked, smallest fixes, new players for the retest.