Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf)
Page 35
The solution requires moving the physical locations of the stovetop knobs so that they better suggest which burners they control. The knobs don’t have to be laid out in exactly the same pattern as the burners, but they should be positioned so that the target of each knob is clear. The stovetop in Figure 11-12 is a good example of an effective mapping of controls.
In this layout, it’s clear that the upper-left knob controls the upper-left burner. The placement of each knob visually suggests which burner it will turn on. Donald Norman (1989) calls this more intuitive layout “natural mapping.”
Another example of poor mapping — of a different type — is pictured in Figure 11-13. In this case, it is the logical mapping of concepts to actions that is unclear.
16_084113 ch11.qxp 4/3/07 6:05 PM Page 244
244
Part II: Designing Behavior and Form
Figure 11-12 Clear spatial mapping. On this stovetop, it is clear which knob maps to which burner because the spatial arrangement of knobs clearly associates each knob with a burner.
Figure 11-13 An example of a logical mapping problem. If a user wants to see the most recent items first, does he choose Ascending or Descending? These terms don’t map well to how users conceive of time.
The Web site uses a pair of drop-down menus to sort a list of search results by date.
The selection in the first drop-down determines the choices present in the second.
When Re-sort Results by: Date Placed is selected in the first menu, the second drop-down presents the options Ascending and Descending.
Unlike the poorly mapped stovetop knobs, the target of this control is clear — the drop-down menu selections will affect the list below them. However, the result of using the control is unclear: Which sort order will the user get if he chooses Ascending?
The terms chosen to communicate the date sorting options make it unclear what users should choose if they wish to see the most recent items first in the list.
Ascending and Descending do not map well to most users’ mental model of time.
People don’t think of dates as ascending or descending; rather, they think of dates and events as being recent or ancient. A quick fix to this problem is to change the wording of the options to Most Recent First and Oldest First, as in Figure 11-14.
16_084113 ch11.qxp 4/3/07 6:05 PM Page 245
Chapter 11: Eliminating Excise
245
Figure 11-14 Clear logical mapping. Most Recent and Oldest are terms that users can easily map to time-based sorting.
Whether you make appliances, desktop applications, or Web sites, your product may have mapping problems. Mapping is an area where attention to detail pays off —
you can measurably improve a product by seeking out and fixing mapping problems, even if you have very little time to make changes. The result? A product that is easier to understand and more pleasurable to use.
Inflect your interface to match user needs
Inflecting an interface means organizing it to minimize typical navigation. In practice, this means placing the most frequently desired functions and controls in the most immediate and convenient locations for users to access them, while pushing the less frequently used functions deeper into the interface, where users won’t stumble over them. Rarely used facilities shouldn’t be removed from the program, but they should be removed from the everyday workspace.
DESIGN
Inflect the interface for typical navigation.
principle
The most important principle in the proper inflection of interfaces is commensurate effort. Although it applies to all users, it is particularly pertinent to perpetual intermediates. This principle merely states that people will willingly work harder for something that is more valuable to get. The catch, of course, is that value is in the eye of the beholder. It has nothing to do with how technically difficult a feature is to implement, but rather has entirely to do with a person’s goals.
If a person really wants something, he will work harder to get it. If someone wants to become a good tennis player, for example, he will get out on the court and play very hard. To someone who doesn’t like tennis, any amount of the sport is tedious effort.
If a user needs to format beautiful documents with multiple columns, several fonts, and fancy headings to impress his boss, he will be highly motivated to explore the recesses of the application to learn how. He will be putting commensurate effort into the project. If some other user just wants to print plain old documents in one
16_084113 ch11.qxp 4/3/07 6:05 PM Page 246
246
Part II: Designing Behavior and Form
column and one font, no amount of inducement will get him to learn those more advanced formatting features.
DESIGN
Users make commensurate effort if the rewards justify it.
principle
This means that if you add features to your application that are necessarily complex to manage, users will be willing to tolerate that complexity only if the rewards are worth it. This is why a program’s user interface can’t be complex to achieve simple results, but it can be complex to achieve complex results (as long as such results aren’t needed very often).
It is acceptable from an interface perspective to make advanced features something that users must expend a little extra effort to activate, whether that means searching in a menu, opening a dialog, or opening a drawer. The principle of commensurate effort allows us to inflect interfaces so that simple, commonly used functions are immediately at hand at all times. Advanced features, which are less frequently used but have a big payoff for users, can be safely tucked away where they can be brought up only when needed. Almost any point-and-shoot digital camera serves as a good example of inflection: The most commonly used function — taking a picture — is provided by a prominent button easily accessible at a moment’s notice. Less commonly used functions, such as adjusting the exposure, require interaction with onscreen controls.
In general, controls and displays should be organized in an interface according to three attributes: frequency of use, degree of dislocation, and degree of risk exposure.
Frequency of use means how often the controls, functions, objects, or displays are used in typical day-to-day patterns of use. Items and tools that are most frequently used (many times a day) should be immediately in reach, as discussed in Chapter 10. Less frequently used items, used perhaps once or twice a day, should be no more than a click or two away. Other items can be two or three clicks away.
Degree of dislocation refers to the amount of sudden change in an interface or in the document/information being processed by the application caused by the invocation of a specific function or command. Generally speaking, it’s a good idea to put these types of functions deeper into the interface (see Chapter 10 for an explanation).
16_084113 ch11.qxp 4/3/07 6:05 PM Page 247
Chapter 11: Eliminating Excise
247
Degree of risk exposure deals with functions that are irreversible or may have other dangerous ramifications. Missiles require two humans turning keys simultaneously on opposite sides of the room to arm them. As with dislocating functions, you want to make these types of functions more difficult for your users to stumble across. The riskiness of an undesirable can even be thought of as a product of the event’s likelihood and its ramifications.
Of course, as users get more experienced with these features, they will search for shortcuts, and you must provide them. When software follows commensurate effort, the learning curve doesn’t go away, but it disappears from the user’s mind —
which is just as good.
Avoid hierarchies
Hierarchies are one of the programmer’s most durable tools. Much of the data inside applications, along with much of the code that manipulates it, is in hierarchical form. For this reason, many programmers present hierarchies (the implementation model) in user interfaces. Early menus, as we’ve seen, were hierarchical.
But abstract hierarchies are very difficult for users to successfully navigate, except where they’re based on user mental models and the categories are truly mutually exclusive. This truth is often difficult for programmers to grasp because they themselves are so comfortable with hierarchies.
Most humans are familiar with hierarchies in their business and family relationships, but hierarchies are not natural concepts for most people when it comes to storing and retrieving arbitrary information. Most mechanical storage systems are simple, composed either of a single sequence of stored objects (like a bookshelf) or a series of sequences, one level deep (like a file cabinet). This method of organizing things into a single layer of groups is extremely common and can be found everywhere in your home and office. Because it never exceeds a single level of nesting, we call this storage paradigm monocline grouping.
Programmers are very comfortable with nested systems where an instance of an object is stored in another instance of the same object. Most other humans have a very difficult time with this idea. In the mechanical world, complex storage systems, by necessity, use different mechanical form factors at each level: In a file cabinet, you never see folders inside folders or file drawers inside file drawers. Even the dissimilar nesting of folder-inside-drawer-inside-cabinet rarely exceeds two levels of nesting. In the current desktop metaphor used by most window systems, you can nest folder within folder ad infinitum. It’s no wonder most computer neophytes get confused when confronted with this paradigm.
16_084113 ch11.qxp 4/3/07 6:05 PM Page 248
248
Part II: Designing Behavior and Form
Most people store their papers (and other items) in a series of stacks or piles based on some common characteristic: The Acme papers go here; the Project M papers go there; personal stuff goes in the drawer. Donald Norman (1994) calls this a pile cabinet. Only inside computers do people put the Project M documents inside the Active Clients folder, which, in turn, is stored inside the Clients folder, stored inside the Business folder.
Computer science gives us hierarchical structures as tools to solve the very real problems of managing massive quantities of data. But when this implementation model is reflected in the manifest model presented to users (see Chapter 2 for more on these models), they get confused because it conflicts with their mental model of storage systems. Monocline grouping is the mental model people typically bring to the software. Monocline grouping is so dominant outside the computer that interaction designers violate this model at their peril.
Monocline grouping is an inadequate system for physically managing the large quantities of data commonly found on computers, but that doesn’t mean it isn’t useful as a manifest model. The solution to this conundrum is to render the structure as a user imagines it — as monocline grouping — but to provide the search and access tools that only a deep hierarchical organization can offer. In other words, rather than forcing users to navigate deep, complex tree structures, give them tools to bring appropriate information to them. We’ll discuss some design solutions that help to make this happen in Chapter 15.
17_084113 ch12.qxp 4/3/07 6:06 PM Page 249
12
Designing Good Behavior
As we briefly discussed in Chapter 10, research performed by two Stanford sociologists, Clifford Nass and Byron Reeves, suggests that humans seem to have instincts that tell them how to behave around other sentient beings. As soon as an object exhibits sufficient levels of interactivity — such as that found in your average software application — these instincts are activated. Our reaction to software as sentient is both unconscious and unavoidable.
The implication of this research is profound: If we want users to like our products, we should design them to behave in the same manner as a likeable person. If we want users to be productive with our software, we should design it to behave like a supportive human colleague. To this end, it’s useful to consider the appropriate working relationship between human beings and computers.
DESIGN
The computer does the work and the person does the thinking.
principle
The ideal division of labor in the computer age is very clear: The computer should do the work, and the person should do the thinking. Science fiction writers and computer scientists tantalize us with visions of artificial intelligence: computers that think for themselves. However, humans don’t really need much help in
17_084113 ch12.qxp 4/3/07 6:06 PM Page 250
250
Part II: Designing Behavior and Form
the thinking department — our ability to identify patterns and solve complex problems creatively is unmatched in the world of silicon. We do need a lot of help with the work of information management — activities like accessing, analyzing, organizing, and visualizing information, but the actual decisions made from that information are best made by us — the “wetware.”
Designing Considerate Products
Nass and Reeves suggest that software should be polite, but we prefer the term considerate. Although politeness could be construed as a matter of manners and protocol — saying “please” and “thank you,” but doing little else helpful — being truly considerate means being concerned with the needs of others. Above and beyond performing basic functions, considerate software has the goals and needs of its users as a concern.
If an interactive product is stingy with information, obscures its processes, forces users to hunt around for common functions, and is quick to blame people for its own failings, users are sure to have an unpleasant and unproductive experience.
This will happen regardless of how polite, cute, visually metaphoric, anthropomorphic, or full of interesting content the software is.
On the other hand, interactions that are respectful, generous, and helpful will go a long way toward creating a positive experience for people using your product.
DESIGN
Software should behave like a considerate human being.
principle
Commonly, interactive products irritate us because they aren’t considerate, not because they lack features. Building considerate products is not necessarily substantially more difficult than building rude or inconsiderate products. It simply requires that you envision interactions that emulate the qualities of a sensitive and caring person. None of these characteristics is at odds with more pragmatic goals of functional data processing (which lies at the core of all silicon-enabled products).
In fact, behaving more humanely can be the most pragmatic goal of all, and if orchestrated correctly, this kind of dialogue with users can actually contribute to effective functional execution of software.
Humans have many wonderful characteristics that make them considerate, and some of these can be emulated to a greater or lesser degree by interactive products.
17_084113 ch12.qxp 4/3/07 6:06 PM Page 251
Chapter 12: Designing Good Behavior
251
We think the following describe some of the most important characteristics of considerate interactive products (and humans):
Take an interest
Are deferential
Are forthcoming
Use common sense
Anticipate people’s needs
Are conscientious
Don’t burden you with their personal problems
Keep you informed
Are perceptive
Are self-confident
Don’t ask a lot of questions
Take responsibility
Know when to bend the rules
We’ll now discuss these characteristics in detail.
Considerate products take an interest
A considerate friend wants to know more about you. He remembers your likes and dislikes so that he can please you in the future. Everyone appreciates being treated according to his or her own personal tastes.
Most software, on the other hand, doesn’t know or care who is using it. Little, if any, of the personal software on our personal compute
rs seems to remember anything personal about us, in spite of the fact that we use it constantly, repetitively, and exclusively. A good example of this behavior is the way that browsers such as Firefox and Microsoft Internet Explorer remember information that users routinely enter into forms on Web sites, such as a shipping address or username.
Software should work hard to remember our habits and, particularly, everything that we say to it. From the perspective of the programmer writing an application, it can be tempting to think about gathering a bit of information from a person as similar to gathering a bit of information from a database — every time the information is needed, the product asks the user for it. The application then discards that tidbit, assuming that it might change and that it can merely ask for it again if
17_084113 ch12.qxp 4/3/07 6:06 PM Page 252
252
Part II: Designing Behavior and Form
necessary. Not only are digital products better suited to recording things in memory than humans are, but our products also show they are inconsiderate when they forget. Remembering the actions and preferences of humans is one of the best ways to create a positive experience with a software-enabled product. We’ll discuss the topic of memory in detail later in this chapter.
Considerate products are deferential
A good service provider defers to her client. She understands the person she is serving is the boss. When a restaurant host shows us to a table in a restaurant, we consider his choice of table to be a suggestion, not an order. If we politely request another table in an otherwise empty restaurant, we expect to be accommodated. If the host refuses, we are likely to choose a different restaurant where our desires take precedence over the host’s.
Inconsiderate products supervise and pass judgment on human actions. Software is within its rights to express its opinion that we are making a mistake, but it is presumptuous for it to judge or limit our actions. Software can suggest that we not