Later, starting around the 1890s with the introduction of electricity, controls could move away from the object itself to other parts of the room. Everything from light switches to operation of machinery could be done away from the object it was affecting. Other mechanical processes, such as shutting off the water to a building, could also be done on-site or nearby.

Telegraphs, and afterwards the telephone, radio, and television allowed people to affect objects from afar, but the controls were always on the object itself (to tune in and to adjust the signal).

Networked devices connected via Ethernet extended controls to objects in other rooms and the internet expanded this range to include the entire wired world. You can now fly robot drone planes on the other side of the globe. The controls are nowhere near what is being controlled.

This presents a bit of a problem for designers. In “traditional” interaction design, the rule is simple: if you can’t directly control the object itself (via physical controls or touchscreen gestures), you put the controls as close as you can to whatever it is you’re manipulating. The reason for this is simple: feedback. When you turn a dial, you can watch or hear something being affected; when you click an icon to make a word bold, you can see it turn bold. But when I set my DVR with a mobile app, how do I know the DVR itself is executing the command? Sure, I can get feedback from the app, but some trust is definitely involved. If I get home and Oprah hasn’t recorded, what do I blame: the device, the connection, the app?

There is also a distinct emotional impact the farther the controls move away from the object itself. Do I want to cook on my stove from a control panel in another room? Perhaps there are use cases when that makes sense, but it definitely would change the nature of working with a stove and how users feel about their interactions. Of course, it’s not always a negative to move controls to be away from the device: the introduction in the 1950s of the remote control only brought users more power and pleasure from their television sets.

So another choice then, for designers, is not just which controls to have, but where to put them: on, near, or remote. And the answer should be one of context: how important and immediate is the feedback (especially multi-sense feedback) to the task, and (related) what will it feel like to use this device from afar: is it empowering or dehumanizing?

Interaction models usually contain the following pieces:

• how to launch or close pieces of functionality
• how to navigate between pieces of functionality
• transitions between pieces of functionality
• how pieces of functionality interact with each other
• sort, manage, and find files or data

In short, interaction models are the means to access and move between functions. Interaction models can be overarching to include the entire device, or they can be contained within a single application or feature.

The desktop metaphor is probably the most famous interaction model. You know how to launch applications, close them, navigate through folders, etc. Over time, pieces have been added to it, like OSX’s Dock or Windows’ Task Bar, but the model has remained remarkably consistent for 30+ years now.

The purpose of an interaction model is to create a logical consistency throughout the device, so that users can determine how to do something and route around any tricky situations. “I’m going to click on this, because in other places, this worked.” The device needs to make sense, to have flow that can be understood. Interaction models create the glue that holds a device together; a box that holds all the functionality.

If we consider what interaction models really are, we begin to realize that they are nothing less than the designer’s attempt to help the user generate a mental model of the device. Mental models are the cognitive method of understanding a device that may or may not be how the device actually works, but allows the user to interact with it. For example, I don’t understand how a car engine works, but I have a mental model in my head of how it does: I steer and push various pedals to make it go forward and stop. We likely create mental models of all sorts of things in the world, not just devices: everything from governments to games. We create representations of external realities and from them derive understanding. Our mental model can be wrong, of course, and that can cause confusion and worse problems.

What then, makes up an interaction model? Metaphors, for one thing. THIS works like THAT. “Your computer works like your desktop.” With devices that have abstract digital behavior, applying a metaphor can make the device more physical, and thus more understandable. A folder is more physical than a directory.

Structure is also a key component in any interaction model: how the functions of a device are positioned in relation to one another. Sometimes this is a matter of information architecture: arranging pieces into a findable information structure, such as into menus and hierarchies. Other times, this is interface or industrial design: grouping controls into a panel that makes sense. It can also be an interaction design task: how do the different panels or windows in an application interact with each other? What are the device defaults, and what can users change?

Interaction models are tied to the device’s functional cartography. Functional cartography is the mapping of features and functions to a device in order to determine which functions are controlled by physical means (mechanical controls), digital means (onscreen controls, sensors), or both. Once the interaction model has been determined, the functional cartography should spring from it.

A through-line is another component of a good interaction model. A through-line is figuring out the likely pathways through the device. A user will do A, then B, then C. Any model should work really well for that A-B-C pathway. A through-line acts as the rhythm section for a rock band does: it shows where the emphasis should be placed and keeps the tasks moving forward.

An interaction model has to fit the device’s major functions, and these can be used as a type of test for any proposed model. “How would this tiling of the screens work with email?” In fact, if an interaction model doesn’t work with any of the major pieces of functionality, it simply might not be the right model. Lesser pieces of functionality can, with some work, often be conformed into fitting into the framework, but everything important should seem “native” to the device: like the device was made to perform those actions. Which, of course, it should be.

The best interaction models are either nearly invisible (that is, they do not get in the way of using the functionality), or else they are extremely pleasing in and of themselves. Transitions and navigation can be done in a manner that is not just a humdrum menu and one screen simply appearing. Think of TiVo’s left-right transitions between screens or the many transitions an iPhone has between applications.

A device without an interaction model will likely seem disjointed and made up of pieces, instead of as a whole. Pieces of functionality will work differently and the overall concept will be hard to grasp. Many mobile phones, appliances, and consumer electronics suffer from this problem. A solid interaction model is the basis for any great device.

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.