Dytbaat Games · making good games greatCopenhagen, Denmark · game design, data and growth

Home › Blog

Playtesting: how to run sessions that change your game

Blog · 18+ · Dytbaat studio
Playtesting: how to run sessions that change your game

Playtesting is the cheapest way to learn the truth about a game and the easiest to do badly. A session that only tells you the game is nice to look at has cost you a week and taught you nothing. The difference is not talent or budget; it is how the session is set up, what you ask, and what you do with the notes afterwards.

Recruiting the right players

The first decision is who sits down, and it matters more than any script. Testing a casual puzzle with hardcore strategy players will tell you about the wrong audience entirely, and testing your tutorial with people who already know the game tells you nothing at all. The right tester is someone from the audience you actually want, and ideally someone who has never seen the build.

Playtesting: how to run sessions that change your game

We try to mix a few first-timers with a few experienced players. The newcomers expose where the game fails to explain itself, and the veterans expose where it stops being interesting. Both are needed, and their feedback should never be pooled into a single number.

What to ask, and what not to ask

The fastest way to ruin a session is to ask players whether they liked it. People are polite, and politeness is useless data. Ask instead what they were trying to do, what they expected next, and where they felt stuck, and let their answers reveal what the game actually communicated.

The best questions are about behaviour in the moment, not opinions after it. A question like what were you about to do is worth ten questions about satisfaction, because it captures the player's intent before they have time to rationalise it.

Watching, not just listening

What players do and what they say often disagree, and the doing is usually closer to the truth. Sitting quietly and watching where the eyes go, when the hand hesitates, and where a face falls tells you more than any survey. Notes taken during play beat recollections taken afterwards.

We keep our own commentary to a minimum. Skipping a hesitation with a helpful hint hides a real problem, and the whole point of the session is to find the problems before real players do. Silence is uncomfortable and it is the most useful thing a tester can offer.

Keeping our own reactions out of the room takes a little discipline. A few habits help us stay quiet and stay useful.

  • Sit beside the player rather than across from them.
  • Say nothing at all for the first five minutes.
  • Note the time of every hesitation, not the reason for it.
  • Ask what happened, never what they thought of it.
  • Resist rescuing a stuck player until the session ends.

None of this is complicated, and it is the part teams skip when they are busy. The value of a playtest lies entirely in the quality of the attention we bring to it, and attention is cheap only if we remember to give it.

Turning notes into fixes

A pile of notes is not a plan. Before changing anything, we sort what we saw into a few categories and decide which one to act on first. The table below is the sort we use, from the most urgent to the least.

What we sawWhat it usually meansWhat we do next
Players could not startThe first minute is unclearFix the opening first
Players were confused mid-loopFeedback is missingClarify the state of play
Players quit without a reasonThe loop lost its pullRe-examine the core
Players asked for a featureOpinion, not evidenceNote it, act later

How many testers is enough

Teams new to testing often wait for dozens of participants before trusting anything. In practice, the biggest problems surface in the first handful of sessions, and the same few issues repeat from then on. Five careful sessions with the right people will find more than twenty careless ones, and they will find them faster.

When the same confusion appears in three testers in a row, we stop testing and start fixing. There is no value in collecting a tenth note about a problem we already understand, and every session we run costs time that could go into the fix.

Running it in the build, not in a meeting

Playtesting is not a milestone; it is a habit. We run short sessions throughout development rather than saving one big test for the end, because a problem found early is cheap to fix and a problem found late is a rework. The build does not need to be pretty for this to work; it needs to be playable enough to reveal what it does.

Testing a rough prototype is uncomfortable for everyone, and it is where the real lessons live. A polished build asks players to admire it, which is the opposite of what we need. The earlier and uglier the test, the more honest the answers.

The habit that pays for itself

If we could keep only one practice from our studio and drop the rest, it would be this one. Playtesting is the only way to replace our assumptions about players with something closer to fact, and the cost is a few hours of watching quietly while someone plays a game we made. Almost every improvement we have shipped began in a session where we said nothing and learned everything.

How we work. Every engagement starts with measurement: we look at how your game actually behaves before we suggest a change. We give honest, evidence-based advice, and we would rather tell you that a feature is working than push a rework you do not need.

Read next

Blog

Mobile game trends worth watching

The shifts in mobile play we follow, and how a small studio reads them without chasing noise.

Blog

Player retention: why players leave and how to win them back

The early signals of churn and the loop changes that give players a reason to return.

Blog

ASO: how players find your game in the store

Store listing basics, the assets that matter and how discovery really works.