What Do You Mean by “Usability”?

(This was originally posted on Matthew Paul Thomas' blog @
http://mpt.net.nz/archive/2008/08/11/usability but has since vanished
from that location. This text was pulled from archive.org.)

The first rule of fight club is, you do not talk about fight club.
Tyler Durden, Fight club

Every so often, in a software project’s mailing list, bug tracker, or
wiki, I see someone suggest a change they claim will “improve
usability”. This is an unhelpful choice of words.

It’s unhelpful because usability has multiple components:

Learnability — how easily a beginner can use the system, and how easily they can become an expert.

Efficiency — how quickly people can achieve what they want.

Memorability — how easily people can remember how to use the system or feature, after not using it for a while.

Safety — how rarely people experience errors, and how easy it is to fix any errors.

Satisfaction — how pleased people are with the overall experience.

Sometimes a design change may be entirely beneficial. Other times, the
change improves one or more of these usability components at the
expense of others.

For example, introducing an assistant to guide people through a
particular task would usually increase learnability and safety, but
reduce efficiency, because even people who knew exactly what they
wanted would still need to navigate through the assistant. (And if you
tried to make the assistant optional, that option itself would be
difficult to understand, reducing learnability.) That doesn’t mean
it’s a bad idea, just that you should compare the costs and benefits.

As another example, adding more keyboard equivalents for menu commands
may increase efficiency, but reduce memorability (because people try
to remember too many) and reduce safety (because an accidental
keypress is more likely to do something surprising).

So, when making a usability suggestion, don’t talk about
“usability”. Instead describe which usability component it would
improve, and for who. For example, “This would be more learnable for
people who have previously used program X”. Or, “This would reduce
errors for people using a pointing device”. Then if there is any
component that would worsen, you can discuss that too, comparing the
number of potential users and how much they’d be affected.

Being precise like this also helps avoid common misconceptions about
usability.

For example, people who think that usability means “dumbing down”
software think it’s all about improving learnability at the expense of
efficiency. They are mistaken: learnability is important, but it’s
only one of the components of usability.

Similarly, people who think that usability means making software
“pretty” think it’s all about improving satisfaction by changing the
visual appearance. They are mistaken too: satisfaction is important,
but it’s only one of the components of usability.

Other software qualities overlap with usability, such as usefulness,
accessibility, reliability, and performance. And there are techniques
for improving usability, such as simplicity, consistency, metaphor,
responsiveness, and commensurate effort. But those are topics for
another day.