How to write a playtest note someone can use

A playtest is wasted when the notes say “felt good” and “needs work.” Those words cannot be built. A useful note points at a moment.

Watch the action, then ask

Let the player try the build before you explain it. The first confusion is the most valuable one, and an explanation deletes it.

When they stop, ask what they were trying to do. Their answer matters more than whether they liked the result. A player who wanted to retreat, and instead jumped forward, has given you a control problem. A player who says the game is cool has given you a compliment.

Use four lines

Every note I keep has the same four lines:

• Where they were in the session.
• What they tried.
• What they expected.
• What the game did instead.

“In the first fight, they tried to save a teammate, expected the heal to land before the next hit, and the teammate died during the cast.” That can be designed. “Healing feels weak” cannot, until you know the moment.

Separate bugs from design

A bug is the game breaking its own rule. A design note is the rule working and still feeling wrong. Write them apart. If you mix them, you will polish a crash and call it balance.

Bugs get a reproduction: the buttons, the mode, and whether it happened once or every time. Design notes get the expectation. Both need the build they were played on, or you will “fix” a version nobody has.

Decide what you will ignore

You will not build every note. Mark the ones that block the loop, the ones several people hit, and the ones that are only taste. Taste can be interesting. It is not an emergency.

On a project like Tingbase, a note about one ability exchange is more useful than a note about the whole game. The exchange is small enough to change. “The match was chaotic” is a mood. Ask which exchange made it chaotic, and write that down instead.

Close the note with a change or a no

End with “change ___” or “no change, because ___.” A note without that ending becomes a backlog graveyard. The point of the playtest is the decision, not the document.

Common questions

What if the tester only says it was fun?

Ask what they tried to do in the minute before they said it. Fun is a result. The note needs the action that caused it.

Should I fix a note the same day?

Fix notes that repeat, or notes that stop the tester from finishing the loop. A single odd death can wait.

How many testers do I need?

A few careful notes beat a pile of scores. Three people hitting the same wall is a real problem.