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.