Usability Principle #3: Reliability
I believe that the next most important usability principle after minimalism and preservation is reliability. Here I do not offer any particularly involved arguments, but instead resort to common sense: how can a tool be useful to us if it is unreliable?
Okay, fine – so we want our widgets to function as advertised; no contest here. But surely no design is intentionally unreliable. And the old 80/20 rule tells us that it can be incredibly expensive to produce a product that is bug/defect free. When we argue for a reliable design, what exactly do we mean?
Of course one enemy of reliability is complexity, but we should have already taken care of that with minimalism. And a major concern with reliability is data corruption or data loss, but we have already taken care of that with preservation. If we rule out obscure and uncommon errors, what’s left? A lot, of course.
A big part of reliability is availability, and high availability is very much a design-time decision. It has everything to do with redundancy. Google, with its far-flung server farms, does a fantastic job on this point. If I am having a problem with Internet connectivity, one of my first tests is always to see whether I can get a browser to load the Google home page, or whether I can ping the google.com domain. Big as Google is, I am sure they are targets of frequent denial of service and other such attacks, but they always seem to be there. This level of availability is part of the reason that I use their search engine — because it is always there, and it just works.
To me, one of the best ways to judge the reliability of a tool is to ask two questions: 1) what is the main purpose of the tool? and 2) how well does the tool fulfill this purpose? For example, there are a lot of cellular handsets on the market that function as nifty personal organizers and media players, but how well do they receive calls? Is voice quality good? Battery life? What about the ease of placing a call?
If this argument is beginning to sound a bit like minimalism, let’s consider a different angle: let’s examine a relatively minimalist device that falls down here. We have a DVD player that I bought about ten years ago, right around the time when DVD players were first available in the US. Generally speaking, it works fine. However, I find that it chokes on DVD’s encoded with ARccOS, an additional digital rights management layer that Sony has used with some titles. Thus, while my DVD player is more than adequate in most cases, it is unreliable because it cannot play all of the mainline digital video discs. The issue is that the player is too minimalistic — it is not sophisticated enough to follow the instructions provided in ARccOS.
When we are thinking about reliability in our designs, we should be asking ourselves
- whether the feature set is sufficient the main purpose of the tool
- whether the product works as advertised
- whether the design is robust enough to withstand a few “shocks and vibrations” (availability)
- whether it produces frequent errors
- whether changes made with the product will “stick”
Finally, although reliability is important, we can tolerate a product a bit more if our data is not corrupted or lost. For this reason, preservation is more fundamental than reliability.