How do I tell a player their bug is actually intended behavior?

Explain the design reasoning plainly and acknowledge their interpretation was reasonable: 'That is intended, here is why, and I can see how it reads as a bug.' Include the why when you close it. A player who understands the reasoning accepts it; one who is just told they are wrong argues louder.

Is a 'working as intended' report a waste of time?

No, it is design feedback. The behavior may be correct, but the player's confusion is a real usability problem. One such report is noise, but the same 'bug' reported repeatedly means your design is actively misleading players, which is fixable with a clearer signal.

What if many players report the same feature as a bug?

Then the feature is effectively a bug. Tag these reports to spot the pattern; a steady stream of bug reports about one intended behavior means your design needs a clearer cue, a tutorial beat, or an actual change. Persistent confusion is your game telling you the signal is too weak.

How to Tell a Player Their Bug Is Actually a Feature

Quick answer: Treat 'working as intended' reports as design feedback, not user error. Explain the intent clearly, thank them for the signal, and ask whether the behavior should change. If players keep reporting a feature as a bug, the feature is the bug.

Some reports describe behavior that is working exactly as designed. The easy response is "that is intended, closing this." But a player who reports intended behavior as broken has told you something valuable: your design is communicating the wrong thing. The behavior may be correct, but the player's confusion is a real bug in your game's clarity.

A 'Working as Intended' Report Is Still a Signal

If a player expected X and your game does Y on purpose, the gap between expectation and reality is a usability problem even when the code is correct. One such report is noise; the same "bug" reported repeatedly means your design is actively misleading players. The behavior is intended, but the confusion is not, and the confusion is fixable.

Resist the framing that the player made a mistake. They engaged with your game in good faith and it surprised them. That surprise is data about how your design reads to someone who did not build it.

Explain the Intent Without Condescension

When you reply, explain the design reasoning plainly and respectfully: "That is actually intended, the stamina drain is meant to make sprinting a tactical choice. I can see how it reads as a bug, though." Acknowledging that their interpretation was reasonable keeps them onside. "That is how it is supposed to work" alone reads as dismissive.

Closing the report as working-as-intended is fine, but include the why. A player who understands the reasoning accepts it; a player who just gets told they are wrong often disagrees louder.

Track the Pattern and Reconsider the Design

Tag these reports so you can see when a single piece of "intended" behavior generates a steady stream of bug reports. That pattern is your game telling you the design needs a clearer signal, a tooltip, a tutorial beat, a visual cue, or possibly a change. If enough players experience a feature as a bug, the honest conclusion is that the feature is a bug.

Bugnet's labels and saved views let you group working-as-intended reports by the feature they touch, so a recurring confusion surfaces as a trend instead of getting closed and forgotten one report at a time. That trend is some of the most useful design feedback you will get.

If players keep reporting your feature as a bug, believe them. The feature is the bug.