Your users are complaining about an unusable feature in your product. It’s so unintuitive and impossible to understand that they are calling it a “bug” in many angry emails to your support staff.
When the discussion reaches a coder, the issue suddenly gets reclassified as a “badly-designed, but correctly functioning feature”. Out of nowhere, they have rid the problem of its shameful “bug” association and made the whole situation seem a lot less troubling.
Coders fiercely argue that if the feature works as intended — regardless of how unusable it may be — then it is not a bug.
It doesn’t matter that your users can’t figure out what the heck to do with it. Or worse, they make incorrect assumptions about how it should work and get totally surprised by some weird side-effects it causes. For a coder, a bug is something completely different, like an exception or a computation error.
The distinction between a “terribly-designed but correctly-implemented feature” and a “bug” exists only in the coder’s mind. It is a distinction they create due to their professional immaturity. What they are really saying is, “Well, someone else may have designed it badly but I implemented it correctly.” Their focus is on their own priorities. The success of the team, the product and the company are secondary.
Allowing a usability issue’s seriousness to be disregarded in this manner is harmful. Apart from the fact that the issue will very likely get pushed to the bottom of the priority queue, the team could also start to consider your user’s opinions as being less valid than their own. Once that happens, the inmates will be running the asylum. You’ll have a system built by programmers, for programmers.
Engineers however will listen to their user’s complaints and quickly agree that it’s a bug. No debate. If the feature doesn’t work for the users, then it doesn’t work at all. What matters is that it gets fixed.
So how can you help a coder change their attitude towards usability bugs? One method is to have them sit and watch a new user flail around trying to use the feature in question.
But my favorite approach takes almost no effort or time at all. Just ask them,
If this was your competitor’s product, would you still defend it as a working feature?