What feedback to ignore

Taking all feedback seriously does not mean acting on all of it. A design that implements every suggestion becomes a camel, shaped by committee into something nobody wanted. Your job after a playtest is triage: separating reliable signals from noise, and problems from proposed solutions. The single most useful rule is that players are experts on how the game felt and amateurs on how to fix it. Trust the complaint, doubt the prescription.

Some feedback is safe to discount. One-off opinions that no other tester echoes are usually taste, not truth, so log them and wait for a second occurrence. Suggestions that would turn your game into a different game ("this party game needs a tech tree") reflect the tester's preferences rather than your design's problems. Feedback from someone far outside your target audience deserves gentle weighting too: a heavy-strategy devotee reviewing your twenty-minute family game will reliably ask for more complexity the game should not have.

Other feedback must never be ignored, even when you dislike it. Repeated confusion at the same rule is a fact about your game, not about your testers. Anything multiple independent groups report is real. Silence is data too: the mechanic nobody ever engages with, the action nobody takes, the expansion content nobody explores. And any moment where a player felt cheated or checked out entirely is worth investigating even if it only happened once, because feeling-robbed moments kill word of mouth.

A practical filter: when feedback stings, sit with it for a day before deciding. Designers are most tempted to dismiss exactly the feedback that threatens their favorite part of the design, and that part is statistically the most likely to be overbuilt. Conversely, be suspicious of feedback that flatters you. The tester who loves everything is not paying attention, or is being kind, and neither helps you.