You do not need a testing lab, a survey, or twenty participants. For a game the size of a commission, one person who has never seen it will find most of what is wrong with it in twenty minutes.
The difficulty is not finding the person. It is the discipline required to sit next to them and say absolutely nothing.
Why the first person finds the most
The problems that matter are the ones everybody hits: a first level that does not teach, a button nobody sees, a jump that looks possible and is not.
Because everybody hits them, the first person hits them. The second person mostly rediscovers the same list. By the fourth or fifth you are down to genuinely individual quirks, which are worth knowing about and rarely worth acting on.
This is why the useful advice is to test early with one person rather than late with ten. One person before the artwork exists, playing a game made of rectangles, will tell you more than a room full of people playing the finished thing, because at that point the finding is still cheap to act on. That ordering is the argument in why game artwork gets drawn twice.
The rule
Say nothing.
Do not explain the controls. Do not say "try jumping". Do not answer "what am I meant to do here", which they will ask, and which is the single most valuable moment in the entire session. Say "I can't help, just do whatever seems right", and write down the time.
The reason this is a rule rather than a preference is that help is irreversible. The instant you tell somebody the collectibles are on the shelves, there is no longer a person in the room who does not know that, and the question of whether the game communicated it is unanswerable forever.
It is genuinely uncomfortable. Watching somebody struggle with something you built, in silence, while they get it wrong in a way that feels obviously avoidable, is unpleasant. That discomfort is the point: it is exactly the discomfort every future player will experience, delivered to the one person who can do something about it.
Watch the hands, not the face
What to record is narrower than people expect.
Hesitation. Any pause where they are deciding rather than doing. Mark the timestamp and what was on screen. That is the raw data and it is nearly all of the value.
Repeated failure at the same spot. Once is learning. Four times is a design problem.
Anything they do that you did not anticipate. Walking left at the start. Trying to jump on an enemy. Pressing every key to see what happens. These reveal what the game appears to invite, which is often not what it meant to invite.
Where they stop. If somebody puts it down, that point is the most important finding of the session, whatever they say about why.
What not to record: their opinions during play, which are performance, and their suggestions afterwards, which are almost always a fix for the symptom.
Ask the right questions afterwards
Once they have finished or given up, the questions worth asking are about what happened, not about what should change.
Where did you get stuck? What were you trying to do at that point? What did you think that thing was? Did you know what you were meant to be collecting?
People are excellent witnesses to their own confusion. They can tell you precisely what they believed and why. They are unreliable designers, and "you should add an arrow pointing at it" is almost never the right response to "I did not see it", where the right response is usually to move it or change its colour.
The rule of thumb is old and holds: listen to the problem, ignore the solution.
Who to ask
The wrong tester is somebody who plays a lot of games, because they will decode anything through familiarity with conventions and tell you it was fine.
The right tester for a commission is somebody as close as possible to the person receiving it. If the game is for a seventy-year-old who has not played anything since a home computer, a seventy-year-old is worth more than a games designer. If it is for a four-year-old, then a four-year-old, and be prepared for the finding that they will do things no adult would ever try.
The one you must not use is yourself. You cannot playtest your own game, ever, for the same reason you cannot proofread your own writing: you see what you meant.
What testing does not cover
Watching a person catches confusion. It does not catch correctness, and the two need different tools.
Whether every collectible in a level is actually reachable, whether the exit can be entered from the direction people approach it, whether the game can be completed at all: those are questions with definite answers, they need to be checked on every build rather than occasionally, and a human being is bad at doing that reliably. They are checked by a program that plays the game, which is the subject of proving a game is actually finished.
The two together are the whole picture. A machine proves it works; a person proves it makes sense.
What this means for a commission
Somebody outside the project plays it before you see it. That is part of the process, not an extra.
The most useful thing you can tell us is who is playing. Age, whether they play games at all, and whether anyone is likely to be helping them.
And the awkward finding is the valuable one. If a tester cannot work out how to start, that is a good outcome discovered at the right time, and it is much cheaper than the same discovery at a party.
