The Features/Usability Bind

One of the implications of Moore's Law, which states that processing power doubles about every eighteen months, is that in about eighteen months you'll be able to buy products that are twice as complicated as the ones you can buy today. This seems inevitable in a commoditized electronic products marketplace, in which manufacturers seem only able to compete based on the number of features they can fit into a product.

The twin trends of technology products are smaller form factors are more features. This leads to what I call the "features/usability bind", in which smaller devices with smaller physical UIs have to access larger numbers of functions. Inevitably, this ends up requiring that input devices (even simple pushbuttons) have to become multi-function; even if the interface remains relatively simple, the underlying functional logic becomes more complex. Furthermore, unless the problem is addressed at the level of the functional logic, complexity will continue to grow with proportionally with features. Perhaps this is why so many electronic products are returned as defective because people can't figure out how to use them.

Engineers have often stated that they expect technological progress to hit a brick wall when the laws of physics catch up with Moore's Law and no more transistors can be crammed onto a chip. I think the real brick wall of technology isn't the number of transistors that can fit on a chip, but rather the number of rules that will fit in a user's head. After all, the user has to learn and remember all the rules that govern how the product works; if these rules aren't intuitive, they must be learned by rote, or the user will simply decide that the feature isn't worth the effort.

I think that there are three basic classes of usability problems associated with electronic products today: modes, convoluted functional logic, and hidden functions. Let me briefly describe each, as I see them.

The technical definition of "modes" from a UI perspective is when the same user action produces different results when the control or system is in different states. A mode error led to the crash of an Airbus A320 in Strasbourg, France, when the pilot, attempting to dial a 3.3 degree flight path angle into the autopilot, instead selected the vertical speed mode, causing the value to actually be 3300 feet per minute. Mode errors in consumer electronics products don't usually have such dramatic consequences, but they can be annoying. One that I typically encounter is when I try to change the channel on my satellite TV receiver but instead cause the TV to revert to "tuner" mode because the remote was in TV mode, and the TV thought I was trying to change its internal tuner channel. A lot of people have come up after presentations to tell me that they've tossed the universal remote control and gone back to the five separate ones because they were tired of making similar errors all the time.

Convoluted functional logic is when accessing a function requires following a complex or hard-to-recall series of steps. For example, storing a phone number in a speed dial location of a phone that I have requires you to press PROG to put the phone into "program" mode, then press the speed dial button where you want to store the number, then dial the number on the keypad, then press another speed dial button labeled MEMORY which, when the phone is in program mode, stores the number you just typed into the memory location you selected at the start of the sequence. Then, you press PROG to take the phone out of "program" mode and put it back into "phone" mode. (This example has the added benefit of again demonstrating a problem with modes.) Another example would be that, on a minidisc recorder I used to own, you had to press and hold the RECORD button and simultaneously press the VOLUME button in order to select manual record level. Have you ever had trouble figuring out how to turn off the alarms on a hotel clock radio? Convoluted logic was probably the culprit.

Hidden functions are typically press-and-hold functions that aren't revealed anywhere in the interface. A friend of mine had to leave a car wash once because he couldn't get the antenna down; when he pressed the radio POWER button, the system would alternate between radio and CD player. It turned out that he had to press and hold the button for a second or so in order to actually turn the power off.

I'll bet that most of the problems people have using products are due to one of these three classes of problems, and not to poor design of the interface itself. One of the ironies is that modes, for example, are often intended to simplify product use by collecting similar functions into the larger umbrella of a mode. But then the user has to learn about the modes, and they themselves become a source of complexity. This is why mode errors have been implicated in several aircraft accidents and at least one cruise ship accident in recent years.

Ultimately, these three classes of problems represent rules that the user must learn and remember. I think we're already at a point where people don't use all the features of products they already own, so trying to sell them new products based on additional features may soon become a losing proposition.

In my view, the best way out of the features/usability bind is to decouple the conceptual complexity of the product from the functional complexity, so the user doesn't have to learn new rules in order to use new features. Note that this is not an interface-level problem. If the functional logic is hard to use, the best interface in the world won't make the product easy to use. One strategy is to apply appropriate metaphors at the level of the product's logic, rather than just the interface. We're used to thinking about metaphors in terms of what icons represent, how radio buttons and check boxes work, and so forth. But the principles of metaphors can be carried to the level of the logic and, ideally, applied across the entire range of product functions. In other words, make the product work like the user thinks, so the user doesn't have to learn how the product works.

The desktop metaphor of the Mac and Windows interfaces is a good example of this, because it re-defines the underlying functions of the operating system into a conceptual world that the user already knows. And it offers a way out of the functions/usability bind. After all, Windows is substantially easier to use than DOS was, but it's infinitely more functionally complex.