It’s a bug, Jim, but not as we know it

Somewhere, in most organizations’ bug-tracking system, there’s a dark corner. It’s a place where – at best – people go to have an opinionated argument. At worst, it’s a place that bugs go to die. It’s the usability bug receptacle.

Often, anything perceived as being related to usability is sent to this container, separate from the real, proper bugs. Perhaps every now and then a couple of easy-looking ones will be picked out and resolved.

This is a fabulously common anti-pattern. But it doesn’t have to be this way – and it shouldn’t be. Usability bugs are real bugs, and it’s perfectly practical to describe, classify, and prioritize them with everything else.

Usability bugs are just bugs

You may be able to conceptually divide your software (application, website, whatever) into whether it is technically working incorrectly, or whether it’s impossible for humans to use. But for the human on the end of it, these two things are exactly the same. They would like to use your product to achieve X in their life, but for some reason they can’t use it to do X.

Human beings are not interested in whether you have introduced a problem when designing your product or when coding it. They’re all just bugs.

Usability bugs are not opinions

You may have been scarred by people raising “bugs” based on whether they liked something or not. While that opinion may or may not be a useful observation, it doesn’t constitute a bug.

A usability bug is an observed problem. This could be from watching someone use your live product, or from a usability test you ran. If someone encounters a problem using something you’ve designed, you have discovered a bug – when you designed that thing to provide some value to a user and that user has a problem accessing the value, it’s a bug.

Alternatively, it could have come from an “expert” evaluation, such as a heuristic evaluation or cognitive walkthrough. In this case, there is a specific rule that your product is violating – this is not a personal opinion.

Usability bugs, just like all others, should describe the problem that’s been observed and the consequence it has. They shouldn’t be phrased as solutions, in the same way that a technical bug wouldn’t be phrased in terms of how a piece of code needed to be changed.

Usability bugs can be classified with all other bugs

Usability bugs – just like regular bugs – can be classified and prioritized based on their impact. There are plenty of ways of doing this, but my favorite scheme is simple:

• Severe = would prevent the user from completing the task, or causes reputational damage
• Substantial = wastes time, requires workaround, causes frustration
• Minor = purely cosmetic or inconsequential impact

You may need more categories than this, depending on how you classify bugs, but the key factor here is the impact of the observed problem. For example, you often hear UI bugs classed as “cosmetic”. But does that cosmetic flaw mean that people don’t realize they can interact with the thing they need to? Does it stop them doing what they need to do? Does it affect their confidence in your brand? Or is it actually inconsequential?

Come out of the dark and into the light

Treating all your bugs the same will make sure you give appropriate priority to the issues that are holding your users (and your product) back – regardless of whether they’re technical or usability in nature.

It is practical, achievable, and desirable to bring those bugs into the fold: out of their dark little corner and into the bright daylight of regular bug prioritization. And by helping your teams understand that usability bugs are observed problems, have a measurable impact, and can sensibly be prioritized you’ll improve the quality of your processes and product, all at the same time.