What a session is for
A playtest answers questions about the player’s experience: do they understand what to do, where do they get stuck, and when do they enjoy themselves or lose interest? It is separate from checking that the game technically works, which is the job of quality assurance. In a playtest, the game is allowed to be rough, because the point is to watch a person meet it for the first time.
Decide what you want to learn
Start with a short list of questions. “Is the game fun?” is too broad to act on. Better examples are: “Do players find the first key without help?”, “Do they understand how to dodge?” or “Where do they pause for more than a minute?”
A focused session tends to produce clearer results than a general one. If the build has several areas, pick one or two to examine. If a question can be answered by looking at the design itself, answer it there and spend the players’ time on the uncertain parts.
Choose the right players
Feedback is only useful if the players resemble the people you hope will buy the game. Friends and family are convenient, but they often want to be kind and may already know the project. A few strangers from the intended audience usually say more. Variety also helps: include at least some people with less experience, because experienced players quietly fill in gaps that beginners cannot.
Sample size is a question of purpose. A handful of players is usually enough to reveal obvious confusion, since the same problem tends to appear repeatedly. It is not enough to estimate how many people in general would like the game, and a small session should never be presented as if it were a measurement of the market. Sessions with more players, or repeated rounds, are more reliable for comparing versions.
Prepare the build and the room
Before anyone arrives:
- Run through the build yourself to make sure it starts and the section you want to test is reachable.
- Prepare a way to reset the game quickly between players, with the same starting state each time.
- Decide how you will record: notes, screen capture, a camera on the player’s hands, or all of these.
- Get permission to record, explain how footage will be stored and respect anyone who declines. Take extra care with children, and involve a parent or guardian.
- Write a short script so every player hears the same introduction.
The introduction
Tell players what you are testing and what you are not. A typical script might explain that the game is unfinished, that problems found are the point, and that the player is not being tested. Say that they can stop at any time. Ask them to think aloud if they are comfortable doing so, describing what they are looking at and what they expect to happen.
Avoid explaining the game. If you describe the controls or the goal, you have removed the thing you came to observe.
Watch silently
This is the hardest part for the people who made the game. When a player is stuck, the instinct is to hint. Resist it. The struggle is the data.
Practical habits include:
- Sit behind or beside the player, not in view.
- Keep your face neutral. A wince or a nod will be noticed.
- If the player asks a question, turn it back: “What do you think you should do?”
- Set a limit in advance, such as five minutes stuck, after which you may step in so the session can continue. Record that you did.
Note what players do, not just what they say. Someone may say a tutorial was clear and then press the wrong button three times. Behavior is generally more reliable than opinion, and the two can be compared.
Record observations
Write down moments rather than conclusions. Useful notes include a timestamp, what the player did, what they said and what you suspect was going on. For example: “04:10, walks past the door twice, says ‘Is this a wall?’” Record positive moments as well, such as laughter or a clever solution, since those show what to keep.
If several people help observe, agree on a simple shared format, such as a table with columns for time, location, behavior and notes. Mark anything that is a clear technical fault for the bug tracker. Reports of that kind follow the usual rules of good bug reports, and the rest stays with the design notes.
Ask after the session
Once play ends, a few open questions are better than a long survey:
- What was the most memorable part?
- Was there anywhere you felt lost or unsure?
- What would you tell a friend about this game?
- Was anything frustrating, and why?
Ask for explanations rather than solutions. A player who says the jump feels bad has told you something real; their suggestion for fixing it is less reliable. Treat their requests as clues about the problem.
From notes to changes
After the session, review the notes while they are fresh. Group similar observations: if four of five players missed the same door, that is a pattern. If only one player had trouble, it may be an individual quirk, so watch for it in later sessions before acting. Rank the issues by how many players were affected and how much it hurt the experience, and then change the biggest ones first.
Testing again after changes is important. A fix may solve one confusion and create another, so a new round with fresh players is the only reliable check. Repeating this loop over the course of a project is how rough designs become clearer ones.