The Laws of Interaction Design

Interaction design, being a new field, doesn't have very many hard and fast rules, or "laws," to speak of. In a sense, interaction designers are still figuring out many of the basic principles of the work they do. However, there are a handful of laws that interaction designers have used successfully. Except for Moore's Law, which designers need only understand, not put into practice, these laws should guide the work, not dictate it.

Moore's Law

In 1965, Gordon Moore, a co-founder of microchip maker Intel, predicted that every two years, the number of transistors on integrated circuits (a rough measure of computer processing power) will double.

Amazingly, this is exactly what has occurred and is still occurring, with staggering results. There is more processing power in a modern laptop than in all of NASA's Mission Control Center when the space agency sent a man to the moon in 1969. The fulfillment of Moore's Law is the underpinning for everything from color monitors to video teleconferencing to the ability to run multiple programs at once. Designers can conceive of devices that are faster, smaller, and more powerful than could feasibly have been considered even a decade ago, much less in 1965 when Moore made his prediction. And in two more years, our devices will be faster, smaller, and more powerful still.

Fitts' Law

Published in 1954 by psychologist Paul Fitts, Fitts' (pronounced "fitzez") Law simply states that the time it takes to move from a starting position to a final target is determined by two factors: the distance to the target and the size of the target. Fitts' Law models the act of pointing, both with a finger and with a device like a mouse. The larger the target, the faster it can be pointed to. Likewise, the closer the target, the faster it can be pointed to.

Fitts' Law has three main implications for interaction designers. Since the size of the target matters, clickable objects like buttons need to be reasonable sizes. As anyone who has tried to click a tiny icon will attest, the smaller the object, the harder it is to manipulate. Second, the edges and corners of screens are excellent places to position things like menu bars and buttons. Edges and corners are huge targets because they basically have infinite height or width. You can't overshoot them with the mouse; your mouse will stop on the edge of the screen no matter how far you move it, and thus will land on top of the button or menu. The third major implication of Fitts' Law is that pop-up menus that appear next to the object that a person is working on (such as a menu that appears next to an object when the user right-clicks the mouse) can usually be opened more quickly than can pull-down menus at the top of the screen, which require travel to other parts of the screen.

Hick's Law

Hick's Law, or the Hick-Hyman Law, says that the time it takes for users to make decisions is determined by the number of possible choices they have. People don't consider a group of possible choices one by one. Instead, they subdivide the choices into categories, eliminating about half of the remaining choices with each step in the decision. Thus, Hick's Law claims that a user will more quickly make choices from one menu of 10 items than from two menus of 5 items each.

A controversial implication of this law is that it is better for products to give users many choices simultaneously instead of organizing the choices into hierarchical groups, as in drop-down menus. If followed to an extreme, this approach could create some truly frightening designs. Imagine if a content-rich site like Yahoo or Amazon presented all of its links on the home page, or if your mobile phone displayed all of its features on its main screen.

Hick's Law also states that the time it takes to make a decision is affected by two factors: familiarity with the choices, such as from repeated use, and the format of the choicesare they sounds or words, videos or buttons?

The Magical Number Seven

Hick's Law seems to run counter to George Miller's Magical Number Seven rule. In 1956, Miller, a Princeton University psychology professor, determined that the human mind is best able to remember information in chunks of seven items, "plus or minus two." After five to nine pieces of information (for instance, navigation labels or a list of features or a set of numbers), the human mind starts making errors. It seems that we have difficulty keeping more than that amount of information in our short-term memory at any given time.

Some designers have taken the Magical Number Seven rule to an extreme, making sure that there are never any more than seven items on a screen at any given time. This is a bit excessive, because Miller was specifically talking about bits of information that humans have to remember or visualize in short-term memory. When those bits of information are displayed on a screen, users don't have to keep them in their short-term memory; they can always refer to them.

But designers should take care not to design a product that causes cognitive overload by ignoring the Magical Number Seven rule. For example, designers should never create a device that forces users to remember unfamiliar items across screens or pages. Imagine if you had to type a new phone number on three separate screens of your mobile phone. You'd scramble to do so (if you could!) before the number faded from your short-term memory.

Tesler's Law of the Conservation of Complexity

Larry Tesler, one of the pioneers of interaction design (see the interview with him later in this chapter), coined Tesler's Law of the Conservation of Complexity, which states that some complexity is inherent to every process. There is a point beyond which you can't simplify a process any further; you can only move the inherent complexity from one place to another.

For example, for an e-mail message, two elements are required: your e-mail address and the address of the person to whom you are sending the mail. If either of these items is missing, the e-mail can't be sent, and your e-mail client will tell you so. It's a necessary complexity. But some of that burden has likely been shifted to your e-mail client. You don't typically have to enter your e-mail address every time you send e-mail; the e-mail program handles that task for you. Likewise, the e-mail client probably also helps you by remembering e-mail addresses to which you've sent mail in the past, so that you don't have to remember them and type them in fully each time. The complexity isn't gone, thoughinstead, some of it has been shifted to the software.

Interaction designers need to be aware of Tesler's Law for two reasons. First, designers need to acknowledge that all processes have elements that cannot be made simpler, no matter how much we tinker with them. As The Who told us in their 1966 song "Substitute," the simple things you see are all complicated. Second, designers need to look for reasonable places to move this complexity into the products they make. It doesn't make sense for users to type their e-mail addresses in every e-mail they send when software can handle this task. The burden of complexity needs to be shared as much as possible by the products interaction designers make.

Larry Tesler on the Laws of Interaction Design

courtesy of Larry Tesler

Larry Tesler's resume reads like the history of interaction design. He's worked at Xerox PARC, Apple, and Amazon and is now at Yahoo as vice president of the User Experience and Design group. While at Xerox PARC, he helped develop some of the language of interaction design, including pop-up menus and cut-and-paste editing. His law of the Conservation of Complexity (discussed in this chapter) is known to programmers and designers alike.

You've worked at some of the seminal places for interaction design: Xerox PARC, Apple, Amazon, and now Yahoo. What do they all have in common?

All of them place a high value on both advanced technology and customer delight.

Are there any unbreakable "laws" in interaction design?

Just one. Design for the users.

How did you come up with Tesler's Law of the Conservation of Complexity?

In the early days of our field, when I worked at Xerox PARC, the idea of user interface consistency was new and controversial. Many of us realized that consistency would benefit not only users, but also developers, because standards could be encapsulated in shared software libraries. We made an economic argument: If we establish standards and encourage consistency, we can reduce time to market and code size.

In 19831985, when I was developing the Mac app object-oriented framework at Apple, I advocated a three-layer code model. In addition to the Macintosh Toolboxa shared software libraryand the application itself, I made the case for an intermediate layer that implemented what I called a generic application. A generic application was a real interactive programwith windows, menus, and commandsthat did nothing at all, but did it in a standard way. You could create, open, save, and print documents, but the documents lacked form and were empty of content. You built your actual application by modifying the generic application in an object-oriented way.

To sell the idea to Apple management and independent software vendors, I came up with the Law of Conservation of Complexity. I postulated that every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it.

Because computers back then were small, slow, and expensive, programs were designed to be compact, not easy to use. The user had to deal with complexity because the programmer couldn't. But commercial software is written once and used millions of times. If a million users each waste a minute a day dealing with complexity that an engineer could have eliminated in a week by making the software a little more complex, you are penalizing the user to make the engineer's job easier.

Whose time is more important to the success of your business? For mass-market software, unless you have a sustainable monopoly position, the customer's time has to be more important to you than your own.

What personal qualities do you think make a good interaction designer?

Enough confidence to believe you can solve any design problem and enough humility to understand that most of your initial ideas are probably bad. Enough humility to listen to ideas from other people that may be better than your own and enough confidence to understand that going with other people's ideas does not diminish your value as a designer.

True concern for the comfort and happiness of other people, including your users and your teammates. If you're not teammate friendly, your products won't be user friendly. That does not mean you should cave in under pressure on an important issue when you have data that supports your opinion. But it does mean you should judge success by the success of the product and the team, not just by the success of your own narrow contribution.

There are a lot of other desirable personal qualities for a designer, such as attention to detail, objectivity, appreciation of humor, appreciation of esthetics, and appreciation of data about users and usage.

The Poka-Yoke Principle

Legendary Japanese industrial engineer and quality guru Shigeo Shingo created the Poka-Yoke Principle in 1961 while working for Toyota. Poka-yoke roughly translates in English to mistake proofing: avoiding (yokeru) inadvertent errors (poka). Designers use poka-yoke when they put constraints on products to prevent errors, forcing users to adjust their behavior and correctly execute an operation.

Simple examples of the application of poka-yoke are the cords (USB, FireWire, power, and others) that fit into electronic devices only in a particular way and in a particular place, and thus prevent someone from, say, plugging the power cord into the hole where the headphones go (Figure 3.7). In this way, poka-yoke ensures that proper conditions exist before a process begins, preventing problems from occurring in the first place. Poka-yoke can be implemented in lots of forms: by signs (Do not touch the third rail!), procedures (Step 1: Unplug toaster), humans (police directing traffic around an accident), or any other entity that prevents incorrect execution of a process step. Where prevention is not possible, poka-yoke mandates that problems be stopped as early as possible in the process. Interaction designers should look for opportunities to use the Poka-Yoke Principle.

Figure 3.7. An illustration of the Poka-Yoke Principle. The USB cord will fit into only a particular slot on this laptop computer.

iStockphoto

Direct and Indirect Manipulation

Digital objects can be manipulated in two ways: directly and indirectly. Although technically digital objects can be manipulated only indirectly (you can't touch something that's made of bits and bytes, after all), direct and indirect manipulation represent two ways of thinking about how to work with digital objects.

Direct manipulation is a term coined by University of Maryland professor Ben Shneiderman in the early 1980s. It refers to the process in which, by selecting a digital object with a finger or with a mouse or some other extension of the hand (which is really direct manipulation in and of itself), we can then do something to the object: move it, turn it, drag it to the trash, change its color, and so on. We can mimic an action that we might perform on a similar object in the physical world. For example, we can scale an object by dragging a corner of it as though we were stretching it. Direct manipulation, because it more closely maps to our physical experiences, is supposedly more easily learned and used, especially for manipulating 3D objects in digital space.

In indirect manipulation, we use a command or menu or other means that isn't directly a part of the digital object to alter that object. Choosing the Select All command in the application interface and pressing the Delete key on the keyboard are examples of indirect manipulation. In the past, especially during the years before the Macintosh popularized the GUI, nearly all computer commands were indirect.

Interaction designers need to decide how digital objects in their products can be manipulated: directly, indirectly, or (more and more frequently) in both ways.

Feedback and Feedforward

Feedback, as it is commonly used, is some indication that something has happened. Feedback should occur like crooked voting does: early and often. Every action by a person who engages with the product or service, no matter how slightly, should be accompanied by some acknowledgment of the action: Moving the mouse should move the cursor. Pressing a key on your mobile phone should display a number.

Proceeding otherwise is to court errors, some of them potentially serious. Frequently, if there is no immediate or obvious feedback, users will repeat the action they just didfor instance, pushing a button twice. Needless to say, this can cause problems, such as accidentally buying an item twice or transferring money multiple times. If the button is connected to dangerous machinery, it could result in injury or death. People need feedback.

We know that feedback is essential; designing the appropriate feedback is the designer's task. The designer has to determine how quickly the product or service will respond and in what manner. Should the response be something simple such as the appearance of a letter on a screen (the feedback in word processing for pressing a key), or should it be a complex indicator such as a pattern of blinking LED lights on a device that monitors your stock portfolio?

Related to feedback (and also to affordances) is what designer Tom Djajadiningrat calls feedforward: knowing what will happen before you perform an action. Feedforward can be a straightforward message ("Pushing this button will submit your order") or simple cues such as hypertext links with descriptive names instead of "Here."

Feedforward allows users to perform an action with confidence because it gives them an idea of what will happen next. Feedforward is harder to design into products and services than feedback, but designers should keep an eye out for opportunities to use it.