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.

And yet, some devices certainly are memorable. How is this, and why?

In order to create a product that stands out, you have to think strategically about it. If you design the same device that is already on the market, you create no value for your organization and no reason for a consumer to buy it instead of another device. To paraphrase strategy guru Michael Porter, your device has to be different than your competitors either by performing different functions, or by functioning differently. By doing so, you make it hard to replicate, and thus you have a strategic advantage.

A differentiator is a characteristic that, all other characteristics being equal, would cause a user to choose one device over another. Here are the major possible differentiators a device could have:

• Price. The device is the least expensive one on the market. It has the lowest price point in its category.
• Form. The device looks different than its competitors (more stylish, slimmer, colorful, different materials, etc.).
• Brand. The device has the advantage of a known organization “endorsing” it.
• Quality. The device is well made and durable.
• Technology. The device has the fastest/most powerful/most efficient/novel technology available.
• Functionality. The device does different things than other devices.
• Behavior. The device operates in a manner that others do not.
• Data and Content. The device has data and/or content that no one else has, either through self-generation or via third-parties.
• Community. The device has a strong user base that is difficult to acquire.
• Ecosystem. The device is tightly tied into an ecosystem of other products and services.

I’ve ranked these in order from easiest to replicate or do better, down to those that are very challenging to outdo. The more differentiators a device has near the end of the list, the vastly more difficult it will be for competitors to recreate and catch up. If we take the iPhone, for example, which had many of these differentiators (form, brand, quality, functionality, technology, behavior, ecosystem), some analysts believed it would take Nokia seven years to come up with a similar offering. And even though some of the differentiators (form, quality, functionality, and technology) have been replicated since its launch, and other similar phones might have other differentiators (namely price), the iPhone is still a distinct product because of the other differentiators it still maintains (brand, behavior, and ecosystem).

Differentiators feed into the value proposition for users. “If I use Device X, I will get Y as a result,” with Y being the product differentiators (although users certainly don’t think of them as such). In the past, Y was either usually price or quality, but increasingly the other differentiators play a role as well. Some of these differentiators, of course, can usually only be obtained over time, such as brand and community, but many can be built into the device, via hardware (form, quality, technology) or software (functionality, behavior).

A word of caution here: a shallow differentiator can be just bad design: making the device different for the sake of having a differentiator, not for the purpose of making it better. Worse is adding a feature to have a differentiator, even though it doesn’t support the overall goals of the product concept. This just leads to a confused product. “Our music player has calendaring functionality.” Don’t add a differentiator just because you can, but because it makes sense to do so. It won’t add value and can damage the product and your brand.

There is, however, the “feature paradox” that James Surowiecki points out in a New Yorker article:

[A]lthough consumers find overloaded gadgets unmanageable, they also find them attractive. It turns out that when we look at a new product in a store we tend to think that the more features there are, the better. It’s only once we get the product home and try to use it that we realize the virtues of simplicity.

Companies like features too, for the simple reason that they are considerably easier to sell. They fit neatly into product comparison charts, and it is easy to see how your device (seemingly) matches up against another. But as pointed out above, technology and functionality (the differentiators that usually comprise “features”) will be replicated. Behavior, Data and Content, Community, and Ecosystem are much trickier (although not impossible) to recreate. Paying attention to how features are embodied in the device will make more of a difference in the long-term (and often in the short-term as well) than the fact that there simply are certain features.

It is this How where design really plays its role. How does the user get from feature to feature? How do you access the feature, and how does the device respond once the feature is engaged? How can we encourage a community of use, or create the ecosystem this device lives in?

All of these differentiators, these Hows, should add up to the “of course” moment. Of course it works like that. How else would it work? That’s when you know you’ve gotten the right combination of differentiators to create a high-value product that will be memorable at next year’s CES.

• Tabs: “inch-scale machines that approximate active Post-It notes” Mobile phones, and devices such as mobile cameras and MP3 players fall into this category, although most of these are larger than Weiser likely envisioned. Very few devices currently are as small and light as a pad of post-it notes. Digital watches and some medical devices, perhaps.
• Pads: “foot-scale [devices] that behave something like a sheet of paper (or a book or a magazine)” Laptops, tablet PCs, and e-readers are examples of this category.
• and Boards: “yard-scale displays that are the equivalent of a blackboard or bulletin board” We’re making progress on this front, with large touchscreen walls, not to mention our flat screen TVs.

Clearly, Weiser was thinking mostly of an office/workplace environment with his categorization scheme. If we expand our view out a little more to include homes and public spaces, I think there are some other general types that could be included in Weiser’s categories:

• Dots: tiny, nearly- or completely-invisible devices.
• Boxes: devices that are slightly too large, bulky or heavy to be portable. Kitchen appliances such as toasters and many consumer electronics like stereo equipment fall into this category.
• Chests: large, heavy devices that do not move, such as dishwashers, stoves, and refrigerators.
• Vehicles: large, heavy devices that do move. Yes, cars are devices too, writ large.

It helps to consider these categories, because each brings with it different expectations as to how to engage with the device and what kinds of functionality might be available, not to mention qualities such as durability and cost. Device designers need to be aware of this when considering what form a device should take.

Of course, traditionally, this is has likely been determined before the designer even starts the project: “We need a new line of washing machines. Go make us some.” But in the 21st century, it’s not quite as simple. Frequently now, the starting point is not the form, but instead the functionality, with the form enabling and enhancing that. As electronics and computer components get smaller, it’s easier for what might have been a Box at one point to become a Pad, Tab, or even a Dot and “disappear” all together. There’s more computing power in a digital watch these days than in the NASA capsules that went to the moon. Functionality, and thus form, is more fluid and cross-category.

Of course, a Vehicle is not likely to become a Dot, but the functionality such as a navigation system that might have previously been stored in a car (in the dashboard, say), might now be in the Tab that is your mobile phone.

There is also an emotional response around different forms. We have a different relationship to our mobile phones than we do to our stoves, or to our cars as to our laptops. Some of this is certainly about price point (our cars cost more than our mobile phones), but some is the pure physicality of the object itself. A large, heavy, immobile object usually has more emotional weight than a small, mobile one. If just for the fact that it has a larger spatial (and fixed) presence in a room. You would immediately notice if it was gone. This is a tricky problem as more objects dematerialize and become Dots. Will you feel differently about your TiVo/DVR if there was no Box and no remote (only gestures for control)?

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.

All devices start with an idea. It might not be much of an idea, but you have to start somewhere. However, most ideas are bad. You can make a device from a bad concept, but usually not a great device. Bad ideas, however, can sometimes be refined into good concepts with effort and the ability to tell when the initial idea is bad. This is often much harder than it seems. Many very smart people have chased bad ideas for years and decades.

It doesn’t necessarily matter if the idea for a device has been done, although it helps if the idea was done poorly before. Recreating a successful device is harder than resurrecting a good idea that was executed poorly. (The poor execution could be caused by any number of factors, including the product vision being ahead of the technology to execute it well. This is not necessarily bad.)

In general, ideas come from two main places: creating something entirely new, or combining existing pieces into a new whole. The former is so rare it might not even be worth discussing. Those kinds of ideas usually only exist in philosophy, science, or the arts, not in product design. Product design is an applied art; it relies on not having to recreate the wheel every time, the wheel in this case being components, materials, and the tools and factories used to create the device. Even if you’re using a piece of new technology in the device (and unique technology itself is uncommon), it is usually surrounded by “old” technology.

Ideas are easy to come by. As a theoretical construct, it’s easy to convince yourself it’s great. But until it’s considered, measured against other ideas, sketched, prototyped, refined, and built, it’s difficult to tell if it is worth pursuing. “No ideas but in things,” said William Carlos Williams. Sometimes, even after design and development, a device’s true potential isn’t known until it’s in the marketplace and people use it. But without any of these steps, an idea is just that: an idea. And, unless patented, it is practically worthless. The execution of a concept is (almost) everything.

Sometimes it is almost impossible to tell if a device concept is a bad one at first. But there are warning signs:

• if the concept doesn’t meet a real (voiced or observed) need
• if the concept adds no new (read: better) extension or refinement of an existing device
• if the device relies too heavily on other services not in your control to deliver value
• if the concept’s value cannot be delivered at a price point that users will tolerate

Of course, there are examples that overcome all of these warning signs, and some of these cannot be determined when you first have an idea, only after examining it for a while.

Device concepts are the most interesting when they use a new technology to solve an old problem or use old technologies to solve new problems.