Watch a player. Change your mind. Make a better game.

Your friend says it is good. Now what?

You hand Night Mail to a friend. They miss the first route sign, run out of oil, and ask where to go. You explain the shortcut, point out the counter, and tell them the jump is supposed to be held. They finish and say, “Yeah, that was fun.”

You have learned that your friend can complete the game with you beside them. You may also have learned that they are kind. You have not yet learned whether the game communicates the route, whether the oil decision is understandable, or whether the jump teaches itself.

This does not make the session worthless. The questions and interventions are evidence. The useful move is to record them accurately instead of converting the successful ending into proof that the design works.

A playtest is not a performance review of you as a person. It is an investigation of a version of a game. Keeping that distinction clear makes it easier to hear something inconvenient, and much easier to decide what to change next.

Give the session a question

Bring the experiment plan from lesson five. If your question is whether the route tradeoff is readable, the session should include that decision under conditions where the tradeoff matters. A tester wandering through an unrelated shop will not answer it.

Choose a version and keep it stable during a small set of sessions. Record the version or date, the starting state, the device, and any assistance you provide. If you change the oil cost between every player and forget which version they saw, the notes become difficult to compare.

An early session can be short. Give the player enough time to encounter the question, try a response, and tell you what they thought happened. You do not need to ask them to exhaust every feature. Fatigue can change behavior, especially when the prototype is rough.

Pick participants whose experience is relevant to the question. A first-time player is useful for onboarding. Someone familiar with the genre can help expose a shallow strategy. A person using a phone can reveal touch issues a keyboard player never encounters. No single person stands in for everyone.

Use an opening that makes honesty easier

Try a simple introduction: “This is an unfinished game. I am testing the game, not you. Try to deliver the letter. You can stop whenever you want. If something is confusing, that is useful for me to see.” Tell them if you are taking notes or recording, and ask before recording.

Give the task without giving the strategy. “Deliver the letter” leaves room to see whether the routes make sense. “Save oil by taking the longer path” tells the player the answer you hoped to observe.

If thinking aloud is useful, ask them to say what they are considering. Remember that speaking changes the task. It can slow a timing challenge or make a player more deliberate than usual. For a fast action sequence, you may prefer to observe quietly and ask about a specific moment afterward.

Make the permission to stop real. A participant who is frustrated, tired, or uncomfortable should not have to keep playing to be helpful. Stopping can also be informative, but the person’s comfort takes priority over your notes.

Sort evidence from explanation

Below are notes from a fictional Night Mail session. Decide whether each note is an observation, something the player reported, or a hypothesis from the designer. Then reveal the explanation. The categories help you keep the useful detail without pretending you know more than you do.

A hypothesis is not a bad note. You need hypotheses to design the next version. The mistake is treating one as a fact before you have tested it.

Write down what happened before deciding why

“The player is careless” is an interpretation with an unhelpful judgment attached. “The player entered the dark route with one oil, then returned to the junction” is an observation. “I thought the lantern would refill at the gate” is the player’s reported explanation. Together, those details suggest several possible design questions.

Maybe the gate looks like a refill station. Maybe the player did not notice the route cost. Maybe the earlier tutorial taught a misleading rule. Maybe they understood the risk and were testing it. You can investigate these possibilities. You cannot productively fix “careless.”

Record actions in sequence around the important moment. What did the player look at or interact with? What changed? What did they try next? You do not need a transcript of every second. You need enough context to reconstruct the decision.

Note your own interventions too. If you point at the oil counter, write it down. If the prototype crashes and you manually restore a resource, write that down. These events change what the session can show. An assisted completion is still a completion, but it answers a narrower question.

Be careful about inferring attention. A player looking toward an icon does not prove they read or understood it. Their next action and later explanation can help. Treat observations as pieces of evidence that support or challenge an interpretation, rather than as a magical view into someone’s thoughts.

Know when to stay quiet and when to intervene

A few seconds of uncertainty can be useful. The player may be forming a plan. If you immediately explain the next step, you remove the chance to see whether the game supports that reasoning.

Long, unproductive confusion is different. If the player is stuck on a broken control, repeating an impossible action, or becoming uncomfortable, help or stop the session. You do not need to preserve a perfect experiment at someone else’s expense.

A practical approach is to define a stopping condition before the test. For example: after the player has tried several approaches and says they cannot continue, ask what they expected, then give the minimum help needed to reach the next part. Mark everything after that as assisted.

If the same help is needed repeatedly, that is a design finding. Do not quietly turn yourself into a permanent tutorial system. The game will eventually meet players without you in the room.

Ask about a moment they actually experienced

“Was it fun?” is a reasonable human question, but it is often too broad to guide a revision. Try “At the first junction, what did you think the two paths would cost?” or “What made you return to the bridge?” Those questions connect a report to a specific event.

Ask what the player expected before explaining the rule. Once you reveal the intended behavior, their memory of the moment may shift. Let them describe their interpretation in their own terms first.

Avoid questions that contain your preferred answer. “Was the oil icon too small?” suggests a diagnosis. “What did you think that icon represented?” leaves more room. “Wouldn’t a faster restart help?” asks for agreement. “What were you doing between attempts?” asks for experience.

Feature requests are useful clues, not automatic instructions. If a player asks for a map, find out what problem the map would solve. They may be losing orientation because landmarks are indistinguishable. A map could help, but clearer landmarks might solve the problem with less interface.

Ask what they would want to try next, and what made them stop. These answers can reveal curiosity or fatigue. Treat them as reports from this person in this session, not a forecast of retention or commercial success.

Separate the symptom from the cause

Consider a player who never uses the bridge. That is a symptom. Possible causes include not noticing it, misunderstanding its cost, disliking the risk, knowing a better route, or having no reason to save time. Each cause suggests a different revision.

Arrange your evidence under a few plain questions. Did they notice the option? Did they understand the relevant rule? Could they perform the action? Did the result match their expectation? Did the understood action support an experience they valued? This is a diagnostic aid, not a rigid sequence every player follows.

Fixing the wrong layer can hide the problem. Increasing the bridge reward may raise usage while leaving a misleading icon intact. Adding tutorial text may not help a touch target that is too small. Slowing an enemy may not help an attack whose warning looks like decoration.

Write at least two plausible explanations before choosing a fix. Then ask what observation would distinguish them. If the player can accurately describe the bridge cost but still avoids it, basic understanding is less likely to be the main problem. If they cannot identify the cost, balancing the reward is premature.

You will not always get a clean answer. Early tests are messy, and several causes can coexist. Make the uncertainty explicit. “We suspect the icon because three players described it as a lock” is more useful than “the icon is definitely the problem.”

Choose the next change by what it unlocks

A test can produce twenty notes. Do not turn all twenty into immediate tasks. First identify issues that prevent you from learning about the central question: a crash, an unreadable route, an input that never registers, or a missing ending.

Next, consider problems that repeatedly damage the intended experience. If several players understand the oil tradeoff but describe every route as an obvious calculation, the choice itself deserves attention. A slightly awkward bag animation may matter less at this stage.

Use severity, frequency, confidence, and cost as separate considerations. A severe crash seen once may still deserve urgent attention. A frequent complaint may have an uncertain cause. A cheap revision may be a useful experiment even if it is not the final solution. Do not compress all of these judgments into a fake precision score.

Keep positive observations too. If players enjoy spotting a dry route from a landmark, protect that relationship while revising the map. Otherwise you can fix visible problems and accidentally remove the part that was working.

Play it: improve the jump, break the landing

Play the original jump, then try the bigger version. A change can sound like an improvement while making the existing level work worse. This tiny scene lets you see that mismatch without rebuilding an entire platformer.

Restore the original and test it again. This gives you a concrete comparison: the destination stayed fixed, while the jump changed. Decide whether to keep the original, adjust the landing for the new jump, or investigate a different movement change.

• Before the second attempt, predict whether the ball will land short, on the platform, or beyond it.
• Record the outcome separately from your preference. A missed platform is observable; “the bigger jump feels better” is a different kind of statement.
• Propose the next test with a reason. If you move the platform, say that you are testing a new jump-and-level combination rather than claiming the jump alone fixed the game.

Compare revisions without moving every target

Choose one main change when you can. If you alter the icon, route costs, camera, and deadline together, a better result will be difficult to explain. You may need to make several repairs to create a usable test, but record that limitation.

When comparing versions, consider learning effects. A player who saw version A already knows the route in version B. Their improvement may come from familiarity rather than your revision. Fresh players can help with onboarding comparisons; experienced players can help with later strategic depth.

For a small qualitative test, look for clearer explanations and changed behavior, not statistical certainty. A handful of sessions can expose important problems. It cannot establish a universal success rate for an entire audience. Keep the conclusion proportionate to the evidence.

Suppose three new players all mistake the oil symbol for a lock. You replace it with a labeled counter and visible route costs. In the next sessions, players explain the resource correctly and make different route choices as their oil changes. That supports the revision. It does not prove the full game is balanced or that everyone will enjoy it.

Find the test that could prove your first guess wrong

A player arrives at the dark bridge with no oil. Your first explanation is that the game needs more fuel. But perhaps they never saw the bridge cost, believed lamps refilled automatically, or deliberately chose a risky route. The observation fits several stories.

Choose the next intervention in the case below. Each option has an authored teaching response, not a simulated player or a measured experiment. The aim is to ask what a test can distinguish, rather than guessing the diagnosis the teacher wants.

Make room for the result you did not ask for

A good test question focuses your attention. It can also make you miss something interesting. While watching oil use, you might overlook that a player invents names for the gardens and navigates by those names instead of the map. Keep a small “unexpected” column in your notes.

Do not turn every surprise into a new feature. First describe it. Then ask whether it supports the experience promise, whether more than one person can use it, and what it would cost to preserve. Naming gardens might suggest one readable landmark. It does not automatically require a town-management system.

Read your notes once as someone trying to improve the game and once as someone trying to disprove your conclusion. If you wrote “the new sign fixed the route,” ask whether the returning player simply remembered the answer. A new player can help separate improved communication from familiarity.

Small sessions are valuable for finding concrete problems and generating explanations. They do not establish what all players prefer. Avoid turning three friendly tests into a percentage claim about your audience. Record what the sessions actually let you say, then choose the next useful check.

The same restraint applies to theory. If your notes do not fit your chosen framework, keep the notes. Perhaps a player enjoys repetition because it feels restful. Perhaps a confusing space is intriguing because exploring it is the point. The framework should help you ask a better question, not delete the player’s answer.

Your final course challenge is to make one revision with a written reason and one result that would make you undo it. Test again. Keep the game small enough that changing your mind remains affordable. That habit will take you further than memorizing a shelf of design vocabulary.

Run one session and make one defensible revision

Your final notebook page should contain one claim you can defend and one thing you still do not know. For example: “The labeled oil counter made the route cost easier to explain in these sessions. We still do not know whether the tradeoff stays interesting across ten deliveries.” That is a useful result, not an apology.

1. Choose the question and version from your prototype plan.
2. Invite someone relevant to that question and explain the unfinished nature of the game.
3. Give a task without teaching the strategy. Observe the critical moment and record any help you provide.
4. Ask what they expected at that moment before explaining your intended rule.
5. Separate your notes into observations, player reports, and hypotheses.
6. Choose one hypothesis, make a focused revision, and predict what should change.
7. Test again under recorded conditions. Keep the old version and compare the evidence.

You have a design practice, not just a prototype

Across these lessons, you have written an experience promise, designed a choice, traced a system, planned how to teach it, built an experiment, and learned from another person using it. The game may still be tiny. The important part is that your next decision can now rest on something more useful than hope.

Return to the promise from lesson one. Does it still describe the game you want to make? Perhaps the courier’s appeal turned out to be peaceful route familiarity rather than tense resource management. Perhaps the tradeoff works, but the controls need care. You are allowed to change direction. Keep the evidence that explains why.

From here, choose the next uncertainty that matters most. Build a slightly longer sequence, test on the intended device, explore a visual style, or investigate an engine limitation. Use the reference guides when a concrete tool question appears. You do not need to learn every model, engine, and asset pipeline before making the next small decision.

And give the game another player before you give it another ten features. They will almost certainly do something you did not expect. That is where the next lesson begins.