How do I tell if a bug report is a real bug or player confusion?

Reproduce the scenario and compare the result against what you actually designed, not against what the player wanted or your gut feeling. If the game does what you intended, it is confusion, not a code bug; if it does something unintended, it is a real defect. Check against documented intent, not intuition.

Should I ignore bug reports that are just player confusion?

No. Confusion is a bug in the clarity layer, your design taught the player to expect the wrong thing. One confused player is noise, but repeated confusion about the same feature means your tutorials, signposting, or UI need work, even if the code is correct. Track it like any other signal.

What do I do with reports that turn out to be intended behavior?

Route them to the design queue rather than closing them as user error. Tag them by feature so the pattern is visible; a feature that generates a steady stream of 'is this broken?' reports needs clearer communication. The fix is a tooltip, tutorial beat, or visual cue, not code.

How to Tell Real Bugs From Player Confusion

Quick answer: Reproduce against intended behavior to classify it, but treat repeated confusion as a clarity bug even when the code is correct. The distinction between a real bug and player confusion is real, yet both are signals worth tracking and often worth fixing.

A chunk of your bug reports will describe things working exactly as designed, the player just expected something different. It is tempting to file these as 'user error' and move on. But a report born of confusion still points at a real problem: your game taught the player to expect the wrong thing. Sorting genuine bugs from confusion matters for triage, but dismissing confusion entirely throws away valuable design feedback.

Reproduce Against Intent, Not Against Vibes

To classify a report, reproduce the scenario and compare the result to what you designed, not to what the player wanted. If the game does what you intended, it is not a code bug. If it does something you did not intend, it is. That comparison against documented intent is the clean line between a real defect and a mismatch of expectations.

The trap is judging by your own intuition in the moment, which is biased because you know how the game is supposed to work. Reproduce deliberately and check against the actual design, not your gut sense that 'that seems fine.'

Confusion Is a Bug in a Different Layer

When a report turns out to be intended behavior, do not just close it as user error, ask why the player expected otherwise. One confused player is noise, but the same confusion reported repeatedly means your design is miscommunicating. That is a real bug, it just lives in the clarity layer, in tutorials, signposting, and UI, rather than in the code.

Tag these reports by the feature they touch so the pattern becomes visible. Bugnet's labels and saved views let you group 'works as intended but players keep reporting it' issues, which surfaces exactly the design clarity problems that would otherwise get closed one at a time and forgotten.

Use the Split to Improve Both Layers

Sorting reports into 'real bug' and 'confusion' is not about deciding which to ignore, it is about routing them to the right fix. Real bugs go to code. Confusion goes to design, a clearer tooltip, an extra tutorial beat, a better visual cue. Both queues deserve attention; they just need different people and different solutions.

Over time, the volume in your confusion queue tells you where your game is hardest to understand. A feature that generates a steady stream of 'is this broken?' reports is a feature whose communication needs work, regardless of whether the underlying code is flawless. Treat that signal as seriously as a crash count.

A real bug lives in the code. Confusion lives in the design. Both are bugs worth fixing.