Writing a playtest decision

Start with the choice that could change

A topic is not a decision. “The new onboarding” is a topic. “Do we keep the shared objective hidden until the first round, or teach it before matchmaking” is a decision. It identifies two plausible actions and gives the Engagement somewhere to land.

Use this sentence: We need to decide whether to [action A] or [action B], for [population], before [real milestone]. If only one outcome is acceptable, the work may be validation rather than research. Say that openly so the session is not asked to provide permission for a decision already made.

Name the behaviour, not the answer you hope to hear

Ask what a participant must notice, understand or do for either choice to work. In a live squad test, that might be whether first-time players find the shared objective without a teammate explaining it, whether a losing team can identify a recovery option, or whether players coordinate before the first irreversible choice.

Observable behaviour is harder to bias than a leading question. “Was the objective clear?” invites agreement. Watching where players look, what they try, when they ask for help and what they believe happened gives the interview something concrete to examine.

Choose the smallest method that can answer it

Expert review

Use it to find known interaction, accessibility or information-design problems before recruiting players.

Individual usability session

Use it when one person can encounter the critical path without a live team changing the conditions.

Synchronized multiplayer session

Use it when coordination, social pressure, shared timing, role interaction or live opposition creates the behaviour.

Unmoderated or telemetry work

Use it when frequency across a larger sample matters more than understanding the moment in depth.

A live lobby is expensive in attention and scheduling. Use it because the room is part of the question, not because multiplayer footage looks persuasive in a presentation.

Let the decision determine the cohort

Recruit the people who could produce evidence against the current assumption. A group of genre experts cannot tell you whether a convention is discoverable to newcomers. A room of first-time players cannot tell you whether high-level counterplay survives repeated use. Mixing both can be useful, but only when each group remains visible in the record.

Region, hardware, role, experience and whether participants know each other are test conditions. Do not describe them as demographic decoration after the room has been filled.

Write the evidence rule before the room opens

State what would strengthen either option and what would merely be interesting. A useful rule might require the same breakdown to appear independently across several first-time squads, plus a debrief explanation that matches the observed behaviour. One confident comment is not automatically a finding, and a quiet room is not automatically success.

Also state what would invalidate the session: the wrong build, failed voice, a missing role, a route problem or a teammate teaching the exact behaviour being tested. Recording these limits protects a negative result from being tidied away and a positive result from being made larger than it is.

A request that can survive contact with the session

• Decision: the real alternatives and the milestone they affect.
• Population: who must be able to use the design.
• Behaviour: what participants need to notice, understand or do.
• Comparison: the current build, an alternative, or a declared baseline.
• Evidence: what would change confidence in either direction.
• Limits: what this method, cohort and build cannot establish.
• Next action: who makes the decision when the evidence arrives.

If those seven lines are clear, the recruitment, run sheet and discussion guide can be designed around them. If they are not, adding participants usually adds ambiguity rather than confidence.

A worked example: from “is the new map fun?” to a decision

The example below is illustrative. It is not a delivered Engagement, and no Studio, build or participant in it is real. It exists to show the shape of the conversion, because the first version of a request almost never arrives as a decision.

What arrives: “We want to know if the new map is fun before we ship it.” Fun is not observable, “the new map” names an artefact rather than a choice, and “before we ship” is a deadline rather than a milestone. As written, no session result can be wrong, which means no session result can be useful.

The choice underneath: asking what happens if the answer is no usually surfaces it. Here the team is deciding whether to keep the map’s three-lane layout or cut it back to two before the content lock. That is a real alternative with a real date, and it is narrower than the map as a whole.

The behaviour that separates the options: the three-lane layout is worth keeping only if squads actually use the third lane to reposition after losing a fight. If they funnel back through the same lane regardless, the extra lane is cost without effect. That is observable in a session record, and it does not depend on anyone reporting whether they enjoyed themselves.

The evidence rule, written before the room opens: keep the third lane if repositioning through it appears independently across a majority of squads in the first losing round, with debrief explanations that match what the record shows. Cut it if squads reliably re-enter through the contested lane, or if the only players using the third route are the ones who already knew the map. Declare in advance that a single vocal preference in the debrief does not move this either way.

What the session still cannot settle: whether the map is fun, whether it will hold up after twenty hours of play, and whether players who never reach the losing round would behave the same way. Those limits belong in the request, not in a footnote afterwards, because they are the difference between a decision the team can defend and a number someone can quote out of context.