|The cranky user: "I can't use this"|
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?
"You'll have to wait: the computer is down"
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.
"I can't do that, Dave"
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.
"I just don't think we're compatible"
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.
"Don't do that then"
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.
"Well, at least you're missing something good"
Personally, I'd rather have something mediocre than miss something good.
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?