How to collect feedback

Playtest feedback comes in three forms, and the least reliable one is the one designers focus on most. Observed behavior is the gold standard: where players hesitated, what they misread, when the table went quiet. Answers to specific questions are second. Unprompted opinions ("you should add dragons") are third, useful mostly as a signal that something bothered the player, even when their proposed fix is wrong. Structure your collection around watching first, asking second, and receiving suggestions last.

During the session, write everything down in the moment. Memory is a terrible playtest instrument, and by the end of a two-hour game you will have lost half the small confusions from the first twenty minutes. Many designers keep a simple running log with a timestamp or round number next to each note. If you cannot take notes while teaching and playing, recruit a friend to observe, or record the session with the group's permission.

After the session, a short debrief beats a long one. Five to ten minutes of focused questions while impressions are fresh, then let people go. For groups you cannot debrief in person, a short written form works: a handful of specific questions plus a free-text box. Keep forms under five minutes to complete or people will skim. Standardizing your questions across sessions lets you compare answers between versions, which is where feedback becomes genuinely powerful.

Finally, store feedback against the version that generated it. A note like "combat felt slow" is meaningless six weeks later if you cannot remember whether it referred to the version before or after you cut the counterattack rule. A simple spreadsheet or document per version number is enough. Patterns across versions, the complaint that keeps surviving your fixes, are the loudest signal in the whole process.