Designing Devices

Every button, slider, switch, knob, or dial represents a choice. Two choices, actually: the choice to have it, and the choice to use it.

The first choice is that of the designer. A control, in its most basic form, is the visible manifestation of a piece of functionality. It gives a cue to the user: you can do something here.

The physical characteristics of a control, what interaction designers call affordances, dictate what can be done with it. A button affords pressing, for instance. Thus, the choice of control is important as well. Sliders, for example, are best used for granular control along a continuum, where there are known thresholds at the top and bottom. Switches are good for clear states, e.g. on/off. And so on.

Every decision to add a control, even a simple button, increases the complexity of a device. After all, in this digital age, devices can do almost anything for a user, from adjusting volume to taking pictures to controlling satellites in space. Control of the device can be held completely by the device. It can be completely automatic. In some cases, like for pacemakers, say, you want this. You don’t want to have to tell your heart to beat! The less controls there are, the simpler the device is for a user (although probably not for those involved in making the device).

Of course, by reducing controls (and thus reducing complexity for the user), you also reduce, well, control over the device. Users can do far less with it, and have little to no options for customization. Again, sometimes this is desirable. But sometimes, it is a disaster. Reducing complexity means reducing control, and some users, particularly those whose skill goes beyond that of amateur/beginner, don’t just want control, they need it to perform their tasks effectively. Thus, it becomes a balancing act, with simplicity and automation on one side, and complexity and control on the other.

How you determine which side of the continuum to fall on depends on a number of factors:

• The kind of device it is. Is it a mass-market mobile phone, or an expensive controller for a custom-built home movie theater?
• The kinds of activities the device engenders. Is it a kiosk that will be used sporadically, or an MP3 player that will be used several times a day? Is it a simple activity like listening to music, or a complex one like playing a first-person shooter?
• Who the target users are. Is the device for a broad, mass-market audience, or for a group of specialists like heart surgeons?
• The positioning of the device in the marketplace. Is the device a tool for power users, or a starter device for initiates?
• The emotional feeling you wish the device to convey. Is it something powerful and important, or simple and elegant?

No matter which side you choose, complexity just doesn’t go away. Larry Tesler, creator of such enduring interaction design paradigms like cut-and-paste, has noted this in Tesler’s Law of the Conservation of Complexity. All processes have a core of complexity that cannot be designed away. The only question is what handles it: the system, or the user. By creating a control, the designer is making a choice, saying to the user in effect, “You handle this.” But if the system has to handle the complexity, it means all kinds of decisions have to be made for the user, your defaults have to be smart, and god help you if you get them wrong.

Take for instance a digital camera in which all controls except two have been removed: an on/off switch and a button to take a picture. This means the system either has to handle focusing, picture management, exporting, employing flash, zooming, etc. or else not offer the feature at all. If it’s determined that at least some of these features are crucial to the success of the camera, the resulting complexity which might otherwise be handled by the user has to be determined and built into the hardware and software. Bad choices (i.e. poor defaults) here will ruin the device. Pictures will be overexposed or blurry, users will be frustrated at not being able to zoom, and so on.

Of course, some device manufacturers have taken to spreading the complexity of their devices around, with pieces of functionality residing on the device itself, while others are handled by an application on the web, mobile, or desktop. The obvious example of this is managing your music via iTunes, but the listening and associated functions (rewind, fast forward, etc.) can be done on the device itself. The idea is to reduce the complexity of the device without losing any functionality; it’s just handled on other devices (a laptop/desktop or mobile phone) where a keyboard (and possibly a mouse and a larger screen) might be useful.

Once a control is in place, the second choice is that of the user: the decision to use that control. Designers need to help users make that decision as best as possible by designing the controls and their surrounding environment well. The best controls have three characteristics: an affordance to let the user know the control is there; an indication (often a label) of what the control controls; and feedback to let the user know the control has been used. If any of these characteristics are missing or done poorly (such as an unintelligible icon for a label), the control will lead to doubt. Helping the user understand what will happen when a control is used (so-called “feedforward” (pdf)) is essential to building trust in the device.

Predictability is also important in building trust. Users want to know when a control is operated, it will do the same thing each time. The system has to have an inner logic that, even if the users cannot articulate it, they understand it. Which is why, unless it undoes an action (a la an on/off switch), it’s a good idea to have a control only control one function. Having the same button do different things can be confusing. This is why soft-keys (where an onscreen label indicates a change in the functionality of a physical button) are problematic.

On-screen controls (and increasingly with physical ones as well), can be disabled or hidden when to use them would be dangerous (see: The Poka-Yoke Principle) or ineffective. Hidden controls are often extremely problematic. Users become accustomed to objects (even digital objects) being in the same place, and to remove them is cognitively jarring. Disabling, particularly if, via a tooltip or other means the user is able to determine why it is disabled and how to engage it again, is usually a much better choice.

Positioning and prominence are other important cues for users. A giant green button with a label reading “PUSH ME!” won’t be ignored, while a small switch in a bank of them will need to be scanned for. The one control that will be the most used or is the most important should get visual and/or spatial prominence. It should be clear what the most important (or at least the most drastic) action is. A Hang Up button, although used infrequently (once per call, to be exact), should be emphasized.

It can be good practice to cluster similar or related controls into zones on the interface, e.g. controls for printing on the right, for exporting on the left. Avoid putting “ejector seat” (undoable) controls next to other positive controls. Having Ok next to Cancel is not good practice.

Like all choices when designing devices, arbitrary choices about controls are an anathema to good design. The best technology, the coolest features, can be ruined by poor controls.