Post-Session Surveys: The 5 Questions Worth Asking

You just watched ten strangers play your build. Some loved it, some bounced off within minutes and one person spent twenty minutes stuck on a puzzle you thought was obvious. Now the real work starts: figuring out what actually happened and what to change next.

The post-session survey is your main instrument for that. It is also the part most indie teams get wrong. Surveys end up too long, too vague or so leading that they confirm whatever the developer already believed. This guide covers the five questions worth asking after every playtest, why each earns its place and how to run the survey so answers stay honest.

Why most post-session surveys fail

Before the questions, the failure modes.

• They are too long. A tester who just played for 45 minutes will not write an essay. After the sixth open-ended question you get one-word answers.
• They are leading. "How fun was the combat?" assumes the combat was fun. "Was the tutorial clear?" invites a polite yes.
• They ask for solutions. Testers are excellent at reporting experiences and bad at prescribing fixes. Ask what happened, not what the game should become.
• They arrive too late. Send the survey three days after the session and you get memories, not observations.

A good survey is short, neutral and immediate. Five questions, maybe a rating bolted on if you must. That is enough.

The five questions

1. What was the last thing you did before you stopped wanting to play?

This is the highest-value question you can ask. It points straight at your game's weakest moment, whether that is a boring stretch, a confusing objective or a crash disguised as a feature.

The phrasing matters. "Why did you stop?" sounds like an accusation. "What was the last thing you did" asks for a fact and facts are easier to report honestly. You will often get a specific moment you can then find in the session recording.

2. Where were you confused about what to do next?

Confusion is more valuable than frustration. Frustration means the game is working but too hard. Confusion means the game failed to communicate. Confused testers rarely announce it, they quietly wander, so ask directly.

Compare answers across testers. If three of eight were lost in the same area, you have a signposting or level design problem. If everyone was confused somewhere different, your onboarding has a systemic issue worth a deeper look.

3. What did you expect to happen right before it didn't?

This question catches broken expectations, which are invisible to you because you know how the game works. A tester presses a button expecting a dodge roll, gets nothing and concludes the game is clunky. On your end the button works fine, it just does something else two frames later.

Expectation mismatches are cheap to fix once found. Often a prompt, an animation or an icon can tell players what should happen. Sometimes the right fix is to make the game match the expectation, because the expectation was more intuitive than your design.

4. What would make you come back tomorrow?

Retention questions usually arrive as ratings: "How likely are you to recommend this game?" A number does not tell you what to do on Monday morning. This phrasing forces testers to name the thing that hooks them or admit that nothing does.

The answers sort into three buckets: mechanics they want to master ("I need to beat that boss"), content they did not see ("there was a locked door I never opened") and progression they want to continue ("I want to finish that skill tree"). Those buckets map directly to what you should polish before launch.

5. If you could change one thing, what would it be and why?

Yes, this is a solution question and yes, testers are bad at solutions. Keep it anyway. The value is not the proposed fix, it is the reason behind it. A tester who writes "remove the stamina bar because I never had enough stamina to fight and run" has told you the stamina economy is suffocating and that is a real finding.

Read proposals as symptom reports. One tester asking for a map is an opinion. Four testers asking for a map is a navigation problem and the map is only one of several possible answers.

How to actually run the survey

• Send it within an hour of the session ending, while details are fresh.
• Keep it to five questions plus at most one rating scale.
• Put the open-ended questions first, where tester attention is highest.
• Never defend the game inside the survey. Ask, then stay quiet.
• Read every answer before watching recordings, so the notes tell you what to look for in the footage.
• Follow up individually. A short chat with the tester who described a confusing moment in detail teaches you more than ten extra surveys.

If you run playtests through a platform like PlaytestQuest, the quest surveys are already structured this way, with short open-ended questions attached to each session. Whether you use a platform or a plain form, the principle holds: ask about experiences, not solutions and keep it short enough that honest answers survive to the end.

Questions to leave out

A quick blacklist.

• "How fun was the game, 1 to 10?" Fun is not one thing and a 8 is not actionable.
• "Would you buy this game?" People are bad at predicting their own purchase behavior and politeness does the rest.
• "What features should we add?" Feature wishlists are how scope explodes.
• "Was X clear?" Binary questions get binary answers and tell you nothing about what to fix.

The habit that matters

One short survey after every session beats one elaborate survey after a big milestone. Consistency gives you comparable data across builds: you can watch the "stuck" answers shrink as the game improves and you learn which questions keep earning their place in your next round.

Five questions, sent immediately, phrased neutrally. That is the whole technique. The hard part is resisting the urge to add number six.