Are You Tracking Your Usability Bugs?

The answer is "almost". There are two types of bugs: Reliability and Usability.

A Reliability Bug is an unintended error which causes your application to fail the user. This user can either be a person or another system. An example would be saving "We paid 832$ for an Ultrabook with 4GB RAM" and when opening the document we get "We paid 832$ for an Ultrabook with 5GB RAM". A Reliability Bug does something wrong but nobody noticed it and the user considered the wrong data to be true. An example for a non-person user is the user permission system used by your bank: if the bank's website lets you edit your credit level then you as a person know that something is wrong but the web-interface system trusted the permission system which failed it. As a general rule if you have a Reliability Bug then you don't have a product (with that feature).

All other bugs are Usability Bugs. A Usability Bug is any unintended behavior by the product which is noticed by the user and has impact on the user. Let's look at a few scenarios:
1. The application performed a Divide By Zero, caught the exception and handled it. There is a bug because this behavior was not anticipated by the programmer but it did not have any affect over the user.
2. The application performed a Divide By Zero and now the user has to click "Continue" to ignore the bug. This bug has some impact over the user.
3. The user typed "We paid 832$ for an Ultrabook with 4GB RAM" and then clicked "Save" which caused the application to crash. Now the user has to type the text again. If the user assumed that the document was already saved then this is a Reliability Bug.
4. The user typed "We paid 832$ for an Ultrabook with 4GB RAM" and during type the text was automatically changed to "We paid 832$ for an Ultrabook with 5GB RAM". If the user noticed then this is a Usability Bug otherwise this is a Reliability Bug.

If the application misbehaved in a way that has impact over the user we have a bug. If the bug was noticed by the user and the user can either fix the data, redo some work, or ignore the wrong data then this is a Usability Bug. If the user did not notice the bug and assumes that everything is alright then this is a Reliability Bug.

Developers and companies track Reliability Bugs with great efforts. It is very easy to define what is a Reliability Bug. I am here to tell you that all other bugs are Usability Bugs and too often the definition of these bugs is based on intuition. Intuition is used for severity, cost and value (ROI), market impact and many other very important factors.

The problem with Usability Bugs is that it is very culture oriented. Here is an example for cultures: Office 2003 users, German speakers, Students, Car owners, Parents...
The cost of a bug and the impact over the user is very dependent on the culture. An extreme example is Office 2007 User Interface had many Usability Bugs for Office 2003 users.

When we mark the priority for a non-Reliability Bug we need to ask the following questions:
1. For every culture of users of the product: How much mental effort does it require.
2. For every culture of users of the product: How long does it take. This includes fixing, training, and any other time consuming action.
3. What is the market value of every such culture.
4. Is the impact associated with the specific User Interface that caused it, with the product, or with the company. In other words how long does it take for users to forget what just happened.

It is interesting to see that sometimes a Reliability Bug for one culture could be a Usability Bug for another.


Defining and providing a product is Leadership! You offer your knowledge and abilities to help people with their problems. You want people to follow the rules you offer in order to get the solution they want. It is exactly the same as leading people out of a dark cave.

When your product is ignoring people - this is bad leadership.
When your product is forgetting or making mistakes it is not fit to lead.
You are also a bad leader if you don't understand the user,
and people will not want to follow you if you don't care about them or their time and efforts.

A leader has to be just. Your product must be predictable and must never punish people too severely or inconsistently. Accidentally clicking "Print" instead of "Save" and having to wait for 5 seconds is a punishment but at least it is consistent. If clicking the "Tools" menu delays for 5 seconds every other time (and not all the time) is worse than delaying for 5 seconds every time.

So... Are you really tracking your usability bugs?

For more complete information about compiler optimizations, see our Optimization Notice.