Production

Playtesting on a Budget: Watching Without Explaining

You cannot see your own game with fresh eyes, and you do not need a lab to borrow someone else's. Five quiet observers will teach you more than a month of guessing.

What a playtest is for

A playtest is the process by which a game designer tests a new game for bugs and design flaws before releasing it. The emphasis for a small team is on design flaws: places where players are confused, bored or stuck. Hunting crashes is a separate job, and mixing the two usually means doing both badly.

Who to ask

Not only friends. Friends are kind, and they have heard you describe the game. Use them for early rough builds.
Strangers who like the genre. Local developer meetups, online communities for your genre and student groups are good sources.
Someone who has never played the genre. One such tester will reveal every convention you forgot to teach.

Each person can only give you a first impression once. Do not spend all your fresh testers on the same build.

Running the session

Set one question. "Do players understand the dash?" is answerable. "Is it fun?" is not.
Say almost nothing. Give the tester the build and tell them you are testing the game, not them. Then be quiet.
Do not help. When they are stuck, wait. The length of time they stay stuck is your data. Step in only if they are about to give up.
Ask them to think aloud if they are comfortable doing so.
Record with permission or take notes with timestamps.

What to write down

Where they died or failed, and whether they understood why.
Where they stopped moving and looked around.
What they tried that the game did not allow.
When they laughed, leaned forward or checked their phone.
The exact words they used for things. Their names for your mechanics are often better than yours.

Questions afterwards

Ask open questions and avoid leading ones. "What was that level asking you to do?" is better than "Did you see the lever?". "How would you describe this game to a friend?" shows whether your pitch matches the experience. Ask what they expected to happen at the moment they were surprised.

Reading the results

Trust behaviour over opinions. Players are reliable witnesses of their own confusion and unreliable designers of solutions. When a tester says "add a map", the finding is "I was lost", and there may be cheaper cures, such as a landmark or a better-lit doorway. Look for problems that occur with more than one tester before rebuilding anything; a single odd session is an anecdote.

Remote testing

If you cannot sit beside people, send a build and ask testers to record their screen and voice, or watch over a video call with screen sharing. Add a simple in-game log of deaths and level times so that you have something objective to set beside their comments. Tell testers plainly what is being recorded.

Make it routine

One tester every week or two is better than a large test near the end, when nothing can be changed. Keep a list of findings with three columns: what happened, how many testers it affected, and what you changed. The third column is the one that makes people willing to test for you again.

// Kit Farrowdale // revised 2026-11-12