Begin with a question that can fail
“Is the game good?” asks too much of one session. A useful question points to a moment at the table: Can new players set up from the written instructions? Does the fourth player wait too long between meaningful decisions? Can players explain why the game ended? Write the current version and player count beside the question.
Define what you will observe before you invite anyone. For setup, that might be skipped steps, rulebook searches, wrong component placement, and designer interventions. For pacing, it might be turn duration, idle time, and the point at which attention drops. Observations are more useful than a score because they tell you what to replay.
Choose guided or blind on purpose
A guided session lets the designer explain the game, then watch decisions and friction. It is useful when systems are changing quickly or when you want to isolate a mechanism. A blind session removes the teaching layer: a fresh group uses the prototype packet and rules without normal clarification. It is a test of the packet, wording, component labels, and reference aids as well as the game.
Do not call a session blind if someone teaches setup, explains a legal action, or quietly resolves a rules gap. Those interventions are valuable evidence; write them down. If the packet is not complete enough to hand over, use the Blind Playtest Readiness Checker first.
Protect time for the debrief
Allocate a short opening, a planned play window, and a closing debrief. During the debrief, ask players to reconstruct what happened before asking whether they liked it. Good prompts include “Where did you first hesitate?”, “What did you think you were allowed to do?”, and “What made the game end?” Avoid explaining your intent before they answer; it changes the evidence you are collecting.
Use the Playtest Session Planner to produce a printable agenda. If the available time does not fit a full game, test a deliberate slice such as setup plus one round, a late-game state, or the end condition.
Classify, revise, and retest
Afterward, classify each finding by layer: rulebook wording, component information, setup, flow, decision quality, balance, or production of the session itself. Do not rewrite every layer after one confusing moment. Fix the smallest plausible cause, then recreate the same situation with a fresh or comparable group.
The Issue Log & Priority Tool makes the priority rule visible: blocked progress and repeatable critical failures come before ordinary tuning. When testing a player range, use the Player Count Test Matrix so the convenience of one familiar group does not become a claim about every supported count.
Limits
No template proves that an audience will enjoy a game or that a rulebook works for every group. Test with appropriate players, record what happened, and keep the prototype version tied to each finding. For a concise description of the core written material, see the Rulebook Sections Reference.