A player walks past the exit three times. You point to the doorway. They finish the level, and you leave the session thinking the level works.
The useful moment happened before the hint. They had a goal, searched for a route, and missed the information meant to guide them. A good first playtest preserves that moment long enough to understand it.
This guide is for a small playable build: one room, one encounter, or the opening few minutes. The aim is to leave with a specific change worth testing, rather than a collection of compliments or a sprawling feature list.
Choose one question your build can answer
“Is the game good?” asks a short session to do too much. Choose a question tied to something observable:
- Can a new player work out how to leave the starting room?
- Can they distinguish an enemy attack from a harmless animation?
- Do they understand what they lost when a run ends?
Write down the intended experience before anyone plays. For an opening room, that might be: “The player discovers movement, notices the locked gate, and searches for another route.” Decide what would count as getting through independently and what would count as needing help. Keep that note private; reading it aloud would teach the solution.
Also decide what this build cannot tell you. A room with placeholder sound cannot settle whether the finished audio communicates danger. A session with a close friend cannot establish demand for the game.
Invite someone who does not know the solution
Choose a player whose experience resembles the audience you want to reach. For a game aimed at newcomers, an expert platformer player may breeze past a confusing control prompt. For a demanding tactics game, someone unfamiliar with the genre may struggle for reasons outside the question you are testing.
A friend is a workable start if they have not watched development. Ask what they usually play and which input device they use. Note those details alongside the results. They help explain a session without dismissing it as “the wrong kind of player.”
Check the build launches, the controls work, and you can reset the starting state. Put unrelated developer windows away. If you want to record the screen or voice, ask permission first, explain who will see it, and accept a no. Written notes are enough to begin.
A simple 25-minute session plan
This is a suggested schedule for a short slice, not a rule for every game. Leave breathing room; a useful observation is worth more than finishing every question.
- Minutes 0–3: Explain the session and ask about relevant game experience.
- Minutes 3–15: Let the player try the slice. Observe and take brief notes.
- Minutes 15–22: Ask about specific moments, then allow another attempt if useful.
- Minutes 22–25: Invite final comments, thank them, and write down your immediate findings.
Try this opening script:
“This is an unfinished build, and I want to see how it communicates. You can stop whenever you like. Please start from this screen and play as you normally would. If anything is confusing or surprising, feel free to say so. I may hold back on explaining things so I can see what the game itself tells you.”
Give the instructions an ordinary player would receive. If the shipped game would show a controls screen, include it. If discovering a mechanic is the question, avoid explaining that mechanic beforehand.
Give a goal without giving away the route
For an opening experience, “Start a new game and play until you would naturally stop” can reveal what draws someone forward. For a focused inventory check, a task might be: “Prepare your character for the next fight.” “Open the equipment tab and equip the blue sword” only checks whether someone can follow those instructions.
Keep task wording consistent across players. If you change it midway through a round, record the change; otherwise you may attribute a clearer instruction to a better game interface.
This approach adapts the GOV.UK guide to moderated usability testing: give participants relevant goals without hints about the solution, then watch what they do. Games add a distinction: uncertainty can be intentional. Record whether a player is exploring with purpose, experimenting, or unable to form a next move.
Watch first. Ask about the moment afterward.
Let pauses happen. Avoid approving each correct move or explaining your design when a player criticizes it. Both can turn the session into a conversation about pleasing the developer.
When clarification helps, use a small, neutral prompt:
- “What were you trying to do there?”
- “What did you expect to happen?”
- “What made you choose that route?”
Save questions during intense action for a quieter moment. Talking while dodging can change the performance you are trying to observe. If the player is comfortable with it, ask them to describe their thinking during slower exploration or menus.
If they become stuck, give them time, then ask what they would try next. You do not need to preserve frustration indefinitely. Offer a hint or move to the next section when continuing stops being useful. Mark the intervention clearly: everything afterward happened with help.
The government's guide to facilitating user research explains how praise, clues, and leading questions can influence behavior. The same risk appears when a developer watches someone play their own game.
Keep observation separate from explanation
“The player didn't understand the gate” is an interpretation. “They interacted with the gate twice, searched the room, then asked whether the build was broken” gives you something to investigate.
Copy this compact note format into a document. Use one entry per useful moment:
Build / player / device:
Moment or timestamp:
Goal:
Observed action:
Player's words:
Help given:
Possible explanation:
Next change to test:
Here is a hypothetical entry:
Moment: First locked gate.
Observed: Player returns to the gate three times and tries the attack button.
Player's words: “I thought I had to break it.”
Help: None before this comment.
Possible explanation: The cracked texture suggests destructibility.
Next test: Change the gate's visual treatment while keeping the route unchanged.
The explanation may be wrong. Perhaps the player never saw the alternate path. Keeping the raw observation lets you consider both possibilities.
Turn the notes into one useful revision
After the session, sort issues by what they prevent. A crash or an unreadable essential cue deserves attention before a decorative preference. Separate intended difficulty from missing information: a player who understands a dodge and mistimes it has encountered a different problem from one who never realizes dodging exists.
For each candidate fix, write: “We observed X. We suspect Y. We will change Z and look for this behavior next time.” Prefer a small change that can test the explanation. Changing the lighting, camera, tutorial text, and level layout together makes it harder to learn which change helped.
Ask a fresh player to try an onboarding revision when possible. A returning player already knows the route. They can still tell you about feel or execution, but their second attempt cannot recreate a first discovery.
Small sessions reveal problems and suggest explanations; they do not prove how common a problem is across the whole audience. Keep track of who encountered it, how much it blocked progress, and whether it appears again after the revision.
Finish with a decision you can act on: one issue, one proposed change, and a clear behavior to watch for in the next build. That is enough progress for a first playtest.