A lot of talk about usability focuses on how things work; are they easy or hard to use? However, occasionally, it's important to remember the most basic kind of usability: Can the product be used at all?
A friend of mine has a button which reads "You'll have to wait: The computer is down." It's a common story. Time and time again, customer service people have told me to come back later, call again later, or just wait on hold until the computer is working again. I tell people the same story; "I can't do that, because the tool for doing that is busted."
Things that might be tolerable if they were slow, or simply annoying, can quickly become simply impossible to work with when they don't work at all. Unfortunately, reliability is something that is often sacrificed in the name of other features, such as speed, or bells and whistles.
Reliability, in general, is the ultimate concern; a system that isn't working at all is less useful than any functional system, however awful.
One particularly odious form of failure is intentional failure. Registration keys and similar tools are nominally intended to prevent piracy; in practice, one of the main things they prevent is legitimate use. Most users know the frustration of trying to find a missing product key for a product that needs to work now. I used to use a program. I had a product key for it; that key is now lost. The company will not replace the key. So, now I don't use the software, because I have no way to run it, and it's not worth the money to buy a whole new copy.
Microsoft's recent XP release takes this to a whole new level; rather than simply requiring a key, they require the user to call in to get an updated key any time the computer changes. One user I know spent a month frantically trying to test all of the programs he used to use under previous versions of Windows, and debug them, so he could finalize his hardware configuration so he wouldn't have to call in two or three times a night while trying to debug hardware conflicts.
Shareware programs are generally the mildest offenders; most of them run in some mostly functional state, frequently only nagging the user to pay. One program I used had a particularly elegant solution: The registration procedure was to click on the checkbox labeled "I Paid!" in the software's preferences panel. No key required. A very friendly interface, and one I was happy to pay for -- twice, because my wife uses it too.
A while back, I wanted to read an article on the Web site of a very well-known Washington newspaper. No matter how many times I tried, I couldn't get in; they had a small page asking me to fill out demographic information, but after I filled it out, I just got the same form again. I never did figure out how to get past that -- so now they have a good dozen sets of demographic information which describe a grand total of zero actual page views; hope the advertisers don't mind.
More subtle is the question of compatibility between software versions. Some old programs I used to use on Windows systems no longer work on modern Windows. Gradual changes have resulted in old APIs being entirely phased out, leaving some older programs totally orphaned, and unusable.
In a rare flash of brilliance, my Windows ME system will cheerfully offer to make a DOS-mode shortcut for such programs, but will then reveal that it cannot, in fact, run anything in DOS mode. This practice of teasing the user with the illusion of possibility is particularly inventive, and may be the only way to make an interface worse than simply not having the program run at all.
Compatibility problems can range from the obvious to the very subtle; a well-designed system will do its very best to always at least tell you what's wrong. As an example of getting it right, I offer an example from Nintendo's game library. As an experiment, I put a game which said it worked only on the newer Gameboy Color into an old Gameboy. With no damage to either game or system, it displayed a message informing me that the game only ran on color systems. Nicely done! By contrast, some programs will appear to run for a long time before suddenly failing catastrophically.
The traditional business answer to compatibility problems is a simple one: Don't upgrade. As long as you're running the system on which all your programs were initially developed, they'll probably run without compatibility problems. This reluctance to upgrade has its roots in a real problem with software and APIs; if support for older APIs was more consistent, a lot of companies would be able to take advantage of newer features in other parts of a system.
There's an old joke about a patient who asks a doctor for help. "Doctor, whenever I raise my right arm above my head, I have these horrible pains!" The doctor replies "Well, don't do that then." This response to usability problems is distressingly common.
One program I worked with had exceptionally slow responses to user interface actions, taking as much as a second to highlight a button the user had clicked. If you clicked a button twice, the program crashed. In practice, this was close to totally unusable until the user had been "trained" to the program's quirks. Later, when a feature of the program was identified to cause crashes, the feature was simply removed from the program.
In general, there's not much difference to the user between "don't use this feature" and "this feature doesn't exist." Programmers and designers alike love to advertise large lists of features, but often, the features simply aren't functional enough to be usable. Once, I used a PDA that proudly proclaimed that it offered a WYSIWYG text editor and support for many printers. The only problem? You couldn't print WYSIWYG text from the text editor to most of those printers without hooking up to a desktop computer. In practice, the feature couldn't be used.
The same problems apply to Web pages as software. When I go to some Web pages today, I get a message telling me the site can't be used at all without JavaScript. This is a bit of a step forward; previously it used to just be a blank page if you didn't have JavaScript.
However, in a world of pop-up ads, this isn't a very tempting option; all they're telling me is that, while I can't use their site, at least the site I can't use is probably a very exciting one, full of drama and intrigue. In fact, according to some start pages, JavaScript would allow me to "navigate through their site," and "customize the experience for my specific browser." Should I be glad of these amazing options? I had previously been under the impression that it was possible to navigate some sites without using JavaScript, but perhaps some companies have invented a new way of navigating that doesn't use hyperlinks, or any other browser mechanism that I'm used to and comfortable with. This doesn't help me get the information I need, but at least I'm missing something good.
Personally, I'd rather have something mediocre than miss something good.
One of the most serious usability problems users end up facing is that a given program or Web page simply won't work at all. This may be a result of compatibility issues, some kind of "security" feature, or just plain bugs. No matter how we get there, though, the user is finding the product to be perfectly and totally unusable -- not the result we are probably hoping for.
Action item: Try to estimate the amount of time you spend waiting for software to start working, whether it's a Web server that's temporarily offline, or a program that needs to be reinstalled. How hard do you think it would be to fix some of these things?
Peter Seebach has been having trouble navigating through badly designed pages since before frames and JavaScript existed. He continues to believe that, some day, pages will be designed to be usable, rather than being designed to look impressive. You can reach him at [mailto:crankyuser@seebs.plethora.net] crankyuser@seebs.plethora.net.