Recognition vs. recall

Because we know that computers are better at memory and humans are better at pattern recognition, we design interaction to play to each other’s strengths. One way to relieve human memory requirements in interaction design is by leveraging the human ability for recognition.

You hear people say, in many contexts, “I cannot remember exactly, but I will recognize it when I see it.” That is the basis for the guideline to use recognition over recall. In essence, it means letting the user choose from a list of possibilities rather than having to come up with the choice entirely from memory.

Recognition over recall does work better for initial or intermittent use where learning and remembering are the operational factors, but what happens to people who do learn? They migrate from novice to experienced userhood. In UAF terms, they begin to remember how to make translations of frequent intentions into actions. They focus less on cognitive actions to know what to do and more on the physical actions of doing it. The cognitive affordances to help new users make these translations can now begin to become barriers to performance of the physical actions.

Moving the cursor and clicking to select items from lists of possibilities become more effortful than just typing short memorized commands. When more experienced users do recall the commands they need by virtue of their frequent usage, they find command typing a (legal) performance enhancer over the less efficient and, eventually, more boring and irritating physical actions required by those once-helpful GUI affordances.

Even command users get some memory help through command completion mechanisms, the “hum a few bars of it” approach. The user has to remember only the first few characters and the system provides possibilities for the whole command.

Shortcuts

When expert users get stuck with a GUI designed for translation affordances, it is time for shortcuts to come to the rescue. In GUIs, these shortcuts are physical affordances, mainly “hot key” equivalents of menu, icon, and button command choices, such as Ctrl-S for the Save command.

The addition of an indication of the shortcut version to the pull-down menu choice, for example, Ctrl+S added to the Save choice in the File menu, is a simple and subtle but remarkably effective design feature to remind all users of the menu about the corresponding shortcuts. All users can migrate seamlessly between using the shortcuts on the menus to learn and remember the commands and bypassing the menus to use the shortcuts directly. This is true “as-needed” support of memory limitations in design.

Cognitive affordance visibility

Obviously a cognitive affordance cannot be an effective cue if it cannot be seen or heard when it is needed. Our first guideline in this category is conveyed by the sign in Figure 22-10, if only we could be sure what it means.

If a cognitive affordance is invisible, it could be because it is not (yet) displayed or because it is occluded by another object. A user aware of the existence of the cognitive affordance can often take some actions to summon an invisible cognitive affordance into view. It is the designer’s job to be sure each cognitive affordance is visible, or easily made visible, when it is needed in the interaction.

This example is about a user (shopper) whom we think would rate himself at least a little above the novice level in shopping at his local grocery store. But recently, on a trip to get some deodorant, he was forced to reconsider his rating when his quick-in-and-quick-out plan was totally foiled. First, the store had been completely remodeled so he could not rely on his memory of past organization. However, because he was looking for only one item, he was optimistic.

He made a fast pass down the center aisle, looking at the overhead signs in each side aisle for anything related to deodorant, but nothing matched his search goal. There were also some sub-aisles in a different configuration along the front of the store. He scanned those aisles unsuccessfully. Although the rubber on his shopping cart tires was burning, he felt his fast-shopping plan slipping away so he did what no guy wants to do, he asked for directions.

The clerk said, “Oh, it is right over there,” pointing to one of the upfront aisles that he had just scanned. “But I do not see any sign for deodorant,” he whined, silently blaming himself, the user, for the inability to see a sign that must have been somewhere right there in front on him. “Oh, yeah, there is a sign,” she replied (condescendingly, he thought), “you just have to get up real close and look right behind that panel on the top of the end shelf.” Figure 22-11 shows what that panel looked like to someone scanning these upfront aisles.

In Figure 22-12 you can see the “deodorant” sign revealed if you “just get up real close and look right behind that panel on the top of the end shelf.”

The nice aesthetic end panels added much to the beauty of the shopping experience, but were put in a location that exactly blocked the “deodorant” sign and others, rendering that important cognitive affordance invisible from most perspectives in the store.

When our now-humbled shopper reminded the store clerk that this design violated the guideline for visibility for presentation of cognitive affordances, he was encouraged that he had reached her interaction design sensibilities when he overheard her hushed retort, “Whatever!”. He left thinking, “that went well.”

Cognitive affordance noticeability

When a needed cognitive affordance exists and is visible, the next consideration is its noticeability or likelihood of being noticed or sensed. Just putting a cognitive affordance on the screen is not enough, especially if the user does not necessarily know it exists or is not necessarily looking for it. These design issues are largely about supporting awareness. Relevant cognitive affordances should come to users’ attention without users seeking it. The primary design factor in this regard is location, putting the cognitive affordance within the users’ focus of attention. It is also about contrast, size, and layout complexity and their effect on separation of the cognitive affordance from the background and from the clutter of other user interface objects.

Message lines, status lines, and title lines at the top or bottom of the screen are notoriously unnoticeable. Each user typically has a narrow focus of attention, usually near where the cursor is located. A pop-up message next to the cursor will be far more noticeable than a message in a line at the bottom of the screen.

For some reason, many Websites have very small and inconspicuous log-in boxes, often mixed in with many objects most users do not even notice in the far top border of the page. Users have to waste time in searching visually over the whole page to find the way to log in.

Cognitive affordance legibility

Text legibility is about being discernable, not about the words being understandable. Text presentation issues include the way the text of a button label is presented so it can be read or sensed, including such appearance or sensory characteristics as font type, font size, font and background color, bolding, or italics of the text, but it is not about the content or meaning of the words in the text. The meaning is the same regardless of the font or color.

Cognitive affordance presentation complexity

Support user needs to locate and be aware of cognitive affordances by controlling layout complexity of user interface objects. Screen clutter can obscure needed cognitive affordances such as icons, prompt messages, state indicators, dialogue box components, or menus and make it difficult for users to find them.

Cognitive affordance presentation timing

Support user needs to notice cognitive affordance with appropriate timing of appearance or display of cognitive affordances. Do not present a cognitive affordance too early or too late or with inadequate persistence; that is, avoid “flashing.”

Sometimes getting cognitive affordance presentation timing right means presenting at exactly the point in a task and under exactly the conditions when the cognitive affordance is needed.

Figures 22-13 and 22-14 are photographs of a paper towel dispenser in a public bathroom. They illustrate an example of a good design that involves just-in-time visibility of presentation of a cognitive affordance.

In Figure 22-13, the next available towel is visible and the cognitive affordance in the sketch on the cover of the dispenser clearly says “Pull the towel down with both hands.”

In Figure 22-14 you can see how designers covered the case where the next towel failed to drop down so users cannot grab it. Now a different user action is needed to get a towel, so a different cognitive affordance is required.

Designers provided this new cognitive affordance, telling the user to Push the lever to get the next towel started down into position. When a towel was already in place, this second cognitive affordance was not needed and was not visible, being obscured by the towel, but it does become visible just when it is needed.

When a user wishes to paste something from one Word document to another, there can be a question about formatting. Will the item retain its formatting, such as text or paragraph style, from the original document or will it adopt the formatting from the place of insertion in the new document? And how can the choice be controlled by the user? When you want more control of a paste operation, you might choose Paste Special … from the Edit menu.

But the choices in the Paste Special dialogue box say nothing about controlling formatting. Rather, the choices can seem too technical or system centered, for example, Microsoft Office Word Document Object or Unformatted Unicode Text, without an explanation of the resulting effect in the document. While these choices might be precise about the action and its results to some users, they are cryptic even to most regular users.

In recent versions of Word, a small cognitive affordance, a tiny clipboard icon with a pop-up label Paste Options appears, but it appears after the paste operation. Many users do not notice this little object, mainly because by the time it appeared, they have experienced closure on the paste operation and have already moved on mentally to the next task. If they do not like the resulting formatting, then changing it manually becomes their next task.

Even if users do notice the little object, it is possible they might confuse it with something to do with undoing the action or something similar because Word uses that same object for in-context undo. However, if a user does notice this icon and does take the time to click on it, that user will be rewarded with a pull-down menu of useful options, such as Keep Source Formatting, Match Destination Formatting, Keep Text Only, plus a choice to see a full selection of other formatting styles.

Just what users need! But it is made available too late; the chance to see this menu comes after the user action to which it applied. If choices on this after-the-fact menu were available on the Paste Special menu, it would be perfect for users.

Cognitive affordance presentation consistency

When a cognitive affordance is located within a user interface object that is also manipulated by physical actions, such as a label within a button, maintaining a consistent location of that object on the screen helps users find it quickly and helps them use muscle memory for fast clicking. Hansen (1971) used the term “display inertia” in reference to one of his top-level principles, optimize operations, to describe this business of minimizing display changes in response to user inputs, including displaying a given user interface object in the same place each time it is shown.

When users of an older version of Gmail were viewing the list of messages in the Inbox, the Archive button was at the far left at the top of the message pane, set off by the blue border, as shown in Figure 22-15.

But on the screen for reading a message, Gmail had the Archive button as the second object from the left at the top. In the place where the Archive button was earlier, there was now a Back to Inbox link, as seen in Figure 22-16. Using a link instead of a button in this position is a slight inconsistency, probably without much effect on users. But users feel a larger effect from the inconsistent placement of the Archive button.

Selected messages can be archived from either view of the email by clicking on the Archive button. Further, when archiving messages from the Inbox list view, the user sometimes goes to the message-reading view to be sure. So a user doing an archiving task could be going back and forth between the Inbox listing of Figure 22-15 and message viewing of Figure 22-16.

For this activity, the location of the Archive button is never certain. The user loses momentum and performance speed by having to look for the Archive button each time before clicking on it. Even though it moves only a short distance between the two views, it is enough to slow down users significantly because they cannot run the cursor up to the same spot every time to do multiple archive actions quickly. The lack of display inertia works against an efficient sensory action of finding the button and it works against muscle memory in making the physical action of moving the cursor up to click.

It seems that Google people have fixed this problem in subsequent versions, as attested to by the same kinds of screens in Figures 22-17 and 22-18.

Clarity of cognitive affordances

Use precise wording, carefully chosen vocabulary, or meaningful graphics to create correct, complete, and sufficient expressions of content and meaning of cognitive affordances.

Precise wording

Support user understanding of cognitive affordance content by precise expression of meaning through precise word choices. Clarity is especially important for short, command-like text, such as is found in button labels, menu choices, and verbal prompts. For example, the button label to dismiss a dialogue box could say Return to …, where appropriate, instead of just OK.

The imperative for clear and precise wording of button labels, menu choices, messages, and other text may seem obvious, at least in the abstract. However, experienced practitioners know that designers often do not take the time to choose their words carefully.

In our own evaluation experience, this guideline is among the most violated in real-world practice. Others have shared this experience, including Johnson (2000). Because of the overwhelming importance of precise wording in interaction designs and the apparent unmindful approach to wording by many designers in practice, we consider this to be one of the most important guidelines in the whole book.

Part of the problem in the field is that wording is often considered a relatively unimportant part of interaction design and is assigned to developers and software people not trained to construct precise wording and not even trained to think much about it.

This is one of our favorite examples of precise wording, probably overdone: “Wet Paint. This is a warning, not an instruction.”

This guideline represents a part of interaction design where a great improvement can be accrued for only a small investment of extra time and effort. Even a few minutes devoted to getting just the right wording for a button label used frequently has an enormous potential payoff. Here are some related and helpful sub-guidelines:

As an example of matching the message to the reality of the work domain, signs such as “Keep this door closed at all times” probably should read something more like “Close this door immediately after use.”

When using the same control object, such as a Play/Pause button on an mp3 music player, to control the toggling of a system state, change the object label to show that it is consistently a control to get to the next state. Otherwise the current system state can be unclear and there can be confusion over whether the label represents an action the user can make or feedback about the current system state.

In Figure 22-20 we show an early prototype of a personal document retrieval system. The underlying model for deleting a document involves two steps: marking the document for deletion and later deleting all marked documents permanently. The small check box at the lower right is labeled: Marked for Deletion.

The designer’s idea was that users would check that box to signify the intention to delete the record. Thereafter, until a permanent purge of marked records, seeing a check in this box signifies that this record is, indeed, marked for deletion. The problem comes before the user checks the box.

The user wants to delete the record (or at least mark it for deletion), but this label seems to be a statement of system state rather than a cognitive affordance for an action, implying that it is already marked for deletion. However, because the check box is not checked, it is not entirely clear. Our suggestion was to re-label the box in the unchecked state to read: Check to mark for deletion, making it a true cognitive affordance for action in this state. After checking, Marked for Deletion works fine.

Distinguishability of choices in cognitive affordances

Support user ability to differentiate two or more possible choices or actions by distinguishable expressions of meaning in their cognitive affordances. If two similar cognitive affordances lead to different outcomes, careful design is needed so users can avoid errors by distinguishing the cases.

Often distinguishability is the key to correct user choices by the process of elimination; if you provide enough information to rule out the cases not wanted, users will be able to make the correct choice. Focus on differences of meaning in the wording of names and labels. Make larger differences graphically in similar icons.

This is an unfortunate, but true, story that evinces the reality that human lives can be lost due to simple confusion over labeling of controls. This is a very serious usability case involving the dramatic and tragic October 31, 1999 EgyptAir Flight 990 airliner crash (Acohido, 1999) possibly as a result of poor usability in design. According to the news account, the pilot may have been confused by two sets of switches that were similar in appearance, labeled very similarly, as Cut out and Cut off, and located relatively close to each other in the Boeing 767 cockpit design.

Exacerbating the situation, both switches are used infrequently, only under unusual flight conditions. This latter point is important because it means that the pilots would not have been experienced in using either one. Knowing pilots receive extensive training, designers assumed their users are experts. But because these particular controls are rarely used, most pilots are novices in their use, implying the need for more effective cognitive affordances than usual.

One conjecture is that one of the flight crew attempted to pull the plane out of an unexpected dive by setting the Cut out switches connected to the stabilizer trim but instead accidentally set the Cut off switches, shutting off fuel to both engines. The black box flight recorder did confirm that the plane did go into a sudden dive and that a pilot did flip the fuel system cutoff switches soon thereafter.

There seem to be two critical design issues, the first of which is the distinguishability of the labeling, especially under conditions of stress and infrequent use. To us, not knowledgeable in piloting large planes, the two labels seem so similar as to be virtually synonymous.

Making the labels more complete would have made their much more distinguishable. In particular, adding a noun to the verb of the labels would have made a huge difference: Cut out trim versus Cut off fuel. Putting the all-important noun first might be an even better distinguisher: Fuel off and Trim out. Just this simple UX improvement might have averted the disaster.

The second design issue is the apparent physical proximity of the two controls, inviting the physical slip of grabbing the wrong one, despite knowing the difference. Surely stabilizer trim and fuel functions are completely unrelated. Regrouping by related functions—locating the Fuel off switch with other fuel-related functions and the Trim out switch with other stabilizer-related controls—might have helped the pilots distinguish them, preventing the catastrophic error.

Finally, we have to assume that safety, absolute error avoidance in this situation, would have to be a top priority UX goal for this design. To meet this goal, the Fuel off switch could have been further protected from accidental operation by adding a mechanical feature that requires an additional conscious action by the pilot to operate this seldom-used but dangerous control. One possibility is a physical cover over the switch that has to be lifted before the switch can be flipped, a safety feature used in the design of missile launch switches, for example.

Consistency of cognitive affordances

Consistency is one of those concepts that everyone thinks they understand but almost no one can define.

Being consistent in wording has two sides: using the same terms for the same things and using different terms for different things. The next three guidelines and examples are about using the same terms for the same things.

This example comes from the very old days of floppy disks, but could apply to external hard disks of today as well. It is a great example of using two different words for the same thing in the short space of the one little message dialogue box in Figure 22-22.

If, upon learning that the current disk is full, the user inserts a new disk and intends to continue copying files, for example, what should she click, Retry or Cancel? Hopefully she can find the right choice by the process of elimination, as Cancel will almost certainly terminate the operation. But Retry carries the connotation of starting over. Why not match the goal of continuing with a button labeled Continue?

If a cognitive affordance suggests an action on a specific object, such as “Click on Add Record,” the name or label on that object must be the same, in this case also Add Record.

From more modern days and a Website for Virginia Tech employees, Figure 22-23 is another clear example of how easy it is for this kind of design flaw to slip by designers, a type of flaw that is usually found by expert UX inspection.

This is another example of inconsistency of wording. The cognitive affordance in the line above the Pay Stub Year selection menu says press View Pay Stub Summary, but the label on the button to be pressed says Display. Maybe this big a difference in what is supposed to be the same is due to having different people working on different parts of the design. In any case we noticed that in a subsequent version, someone had found and fixed the problem, as seen in Figure 22-24.

In passing, we note an additional UX problem with each of these screens, the cognitive affordance Select Pay Stub year in the top half of the frame is redundant with Select a year for which you wish to view your pay stubs in the bottom section. We would recommend keeping the second one, as it is more informative and is grouped with the pull-down menu for year selection.

The first Select Pay Stub year looks like some kind of title but is really kind of an orphan. The distance between this cognitive affordance and the user interface object to which it applies, plus the solid line, makes for a strong separation between two design elements that should be closely associated. Because it is unnecessary and separate from the year menu, it could be confusing. For all the years we were available as an HCI and UX resource, we were never asked to help with the design or evaluation of any software by the university. That is undoubtedly typical.

This is the flip side of the guideline that says to use the same terms for the same things. As we will see in the following example, terms such as Add can mean several different but closely related things. If you, the interaction designer, do not distinguish the differences with appropriately precise terminology, it can lead to confusion for the user.

When using Nero Express to burn CDs and DVDs for data transfer and backup, users put in a blank disc and choose the Create a Data Disc option and see the window shown in Figure 22-25.

In the middle of this window is an empty space that looks like a file directory. Most users will figure out that this is for the list of the files and folders they want to put on the disc. At the top, where it will be seen only if the user looks around, it gives the cue: “Add data to your disc.” In the normal task path, there is really only one action that makes sense, which is clicking on the Add button at the top on the right-hand side.

This is taken by the user to be the way you add files and folders to this list. When users click on Add, they get the next window, shown in Figure 22-26, overlapping the initial window.

This window also shows a directory space in the middle for browsing the files and folders and selecting those to be added to the list for the disc. The way that one commits the selected files to go on the list for the disc is to click on the Add button in this window. Here the term Add really means to add the selected files to the disc list. In the first window, however, the term Add really meant proceed to file selection for the disc list, which is related but slightly different. Yes, the difference is subtle but it is our job to be precise in wording.

If a certain set of related parameters are all selected or set with one method, such as check boxes or radio buttons, then all parameters related to that set should be selected or set the same way.

Setting and clearing search parameters for the Find function are done with check boxes on the lower left-hand side (Figure 22-27) and with pull-down menus at the bottom of the dialogue box for font, paragraph, and other format attributes and special characteristics. We have observed many users having trouble turning off the format attributes, which is because the “command” for that is different than all the others.

It is accomplished by clicking on the No Formatting button on the right-hand side at the bottom; see Figure 22-27. Many users simply do not see that because nothing else uses a button to set or reset a parameter so they are not looking for a button.

The following example is an instance of the same kind of inconsistency, not using the same kind of selection method for related parameters, only this example is from the world of food ordering.

In Figure 22-28 you see an order slip for a sandwich at Au Bon Pain. Under Create Your Own Sandwich it says Please circle all selections but the very next choice is between two check boxes for selecting the sandwich size. It is a minor thing that probably does not impact user performance but, to a UX stickler, it stands out as an inconsistency in the design.

We wrap up this section on consistency of cognitive affordances with the following example about how many problems with consistency in terminology we found in an evaluation of one Web-based application.

In this example we consider only problems relating to wording consistency from a lab-based UX evaluation of an academic Web application for classroom support. We suspect this pervasiveness of inconsistency was due to having different people doing the design in different places and not having a project-wide custom style guide or not using one to document working terminology choices.

In any case, when the design contains different terms for the same thing, it can confuse the user, especially the new user who is trying to conquer the system vocabulary. Here are some examples of our UX problem descriptions, “sanitized” to protect the guilty.

Controlling complexity of cognitive affordance content and meaning

Cognitive affordances do not afford anything if they are too complex to understand or follow. Try decomposing long and complicated instructions into smaller, more meaningful, and more easily digested parts.

The cognitive affordance of Figure 22-29 contains instructions that can bewilder even the most attentive user, especially someone in a wheelchair who needs to get out of there fast.

Support user cognitive affordance content understanding through layout and spatial grouping to show relationships of task and function.

Functions, user interface objects, and controls related to a given task or function should be grouped together spatially. The indication of relationship is strengthened by a graphical demarcation, such as a box around the group. Label the group with words that reflect the common functionality of the relationship. Grouping and labeling related data fields are especially important for data entry.

This guideline, the converse of the previous one, seems to be observed more often in the breach in real-world designs.

The Options dialogue box in Figure 22-30, from an older version of Microsoft Word, illustrates a case where some controls are grouped incorrectly with some parameter settings.

The metaphor in this design is that of a deck of tabbed index cards. The user has clicked on the General tab, which took the user to this General “card” where the user made a change in the options listed. While in the business of setting options, the user then wishes to go to another tab for more settings. The user hesitates, concerned that moving to another tab without “saving” the settings in the current tab might cause them to be lost.

So this user clicks on the OK to get closure for this tabbed card before moving on. To his surprise, the entire dialogue box disappears and he must start over by selecting Options from the Tools menu at the top of the screen.

The surprise and extra work to recover were the price of the use of layout and grouping as an incorrect indication of the scope or range covered by the OK and Cancel buttons. Designers have made the buttons actually apply to the entire Options dialogue box, but they put the buttons on the currently open tabbed card, making them appear to apply just to the card or, in this case, just to the General category of options.

The Options dialogue box from a different version of Microsoft PowerPoint in Figure 22-31 is a better design that places all the tabbed cards on a larger background and the OK and Cancel controls are on this background, showing clearly that the controls are grouped with the whole dialogue box and not with individual tabbed cards.

Some parameters associated with a search function in a digital library are shown in Figure 22-32. In the original design, shown at the top of Figure 22-32, the Search button is located right next to the OR radio-button choice at the bottom. Perhaps it is associated with the Combine fields with feature? No, it actually was intended to be associated with the entire search box, as shown in the “Suggested redesign” at the bottom of Figure 22-32.

Here is a non-computer (sort of) example from the airlines. While waiting in Milan one day to board a flight to Eindhoven, passengers saw the display shown in Figure 22-33. As the display suggests, the Eindhoven flight followed a flight to Catalania (in Spain) from the same gate.

As the flight to Catalania began boarding, confusion started brewing in the boarding area. Many people were unsure about which flight was boarding, as both flights were displayed on the board. The main source of trouble was due to the way parts of the text were grouped in the flight announcements on the overhead board. The state information Embarco (meaning departing) was closer to the Eindhoven listing than to that of Catalania, as shown in Figure 22-33. So Embarco seemed to be grouped with and applied to the Eindhoven flight.

Confusion was compounded by the fact that it was 9:30 AM; the Catalania flight was boarding late enough so that boarding could have been mistaken for the one to Eindhoven. Further conspiring against the waiting passengers was the fact that there were no oral announcements of the boardings, although there was a public address system. Many Eindhoven passengers were getting into the Catalania boarding line. You could see them turning Eindhoven passengers away but still there was no announcement to clear up the problem.

Sometime later, the flight state information Embarco changed to Chiuso (meaning closed), as seen in Figure 22-34.

Many of the remaining Eindhoven passengers immediately became agitated, seeing the Chiuso and thinking that the Eindhoven flight was closed before they had a chance to board. In the end, everything was fine but the poor layout of the display on the flight announcement board caused stress among passengers and extra work for the airline gate attendants. Given that this situation can occur many times a day, involving many people every day, the cost of this poor UX must have been very high, even though the airline workers seemed to be oblivious as they contemplated their cappuccino breaks.

In another simple example, in Figure 22-35 we depict a row of push-button controls once seen on a clothes washing machine.

The choices of Hot wash/cold rinse, Warm wash/cold rinse, and Cold wash/cold rinse all represent similar semantics (wash and rinse temperatures settings) and, therefore, should be grouped together. They are also expressed in similar syntax and words so it is consistent labeling. However, because all three choices include a cold rinse, why not just say that with a separate label and not include it in all the choices?

The real problem, though, is that the fourth button, labeled Start represents completely different functionality and should not be grouped with the other push buttons. Why do you think the designers made such an obvious mistake in grouping by related functionality? We think it is because one single switch assembly is less expensive to buy and install than two separate assemblies. Here, cost won over usability.

On an airplane flight once, we noticed a design flaw in the layout of the overhead controls for a pair of passengers in a two-seat configuration, a flaw that created problems for flight attendants and passengers. This control panel had push-button switches at the left and right for turning the left and right reading lights on and off.

The problem is that the flight attendant call switch was located just between the two light controls. It looked nice and symmetric, but its close proximity to the light controls made it a frequent target of unintended operation. On this flight we saw flight attendants moving through the cabin frequently, resetting call buttons for numerous passengers.

In this design, switches for two related functions were separated by an unrelated one; the grouping of controls within the layout was not by function. Another reason calling for even further physical separation of the two kinds of switches is that light switches are used frequently while the call switch is not.

Likely user choices and useful defaults

Sometimes it is possible to anticipate menu and button choices, choices of data values, and choices of task paths that users will most likely want or need to take. By providing direct access to those choices and, in some cases making them the defaults, we can help make the task more efficient for users.

Many user tasks require data entry into data fields in dialogue box and screens. Data entry is often a tedious and repetitive chore, and we should do everything we can to alleviate some of the dreary labor of this task by providing the most likely or most useful data values as defaults.

Many forms call for the current date in one of the fields. Using today’s date as the default value for that field should be a no-brainer.

Here is a serious example of a case where the choice of default values resulted in dire consequences. This story was relayed by a participant in one of our UX short courses at a military installation. We cannot vouch for its verity but, even if it is apocryphal, it makes the point well.

A front-line spotter for missile strikes has a GPS on which he can calculate the exact location of an enemy facility on a map overlay. The GPS unit also serves as a radio through which he can send the enemy location back to the missile firing emplacement, which will send a missile strike with deadly accuracy.

He entered the coordinates of the enemy just before sending the message, but unfortunately the GPS battery died before he could send the message. Because time was of the essence, he replaced the battery quickly and hit Send. The missile was fired and it hit and killed the spotter instead of the enemy.

When the old battery was removed, the system did not retain the enemy coordinates and, when the new battery was installed, the system entered its own current GPS location as default values for the coordinates. It was easy to pick off the local GPS coordinates of where the spotter was standing.

In isolation of other important considerations, it was a bit like putting in today’s date as the default for a date; it is conveniently available. But in this case, the result of that convenience was death by friendly fire. With a moment’s thought, no one could imagine making the spotter’s coordinates the default for aiming a missile. The problem was fixed immediately!

Among the most common violations of this guideline is the failure to select an item for a user when there is only one item from which to select, as illustrated in the next example.

Here is a special case of applying this guideline where there is only one item from which to select. In this case it was one item in a dialogue box list. When this user opened a directory in this dialogue box showing only one item, the Select button was grayed out because the user is required to select something from the list before the Select button becomes active. However, because there was only one item, the user assumed that the item would be selected by default.

When he clicked the grayed-out Select button, however, nothing happened. The user did not realize that even though there is only one item in the list, the design requires selecting it before proceeding to click on the Select button. If no item is chosen, then the Select button does not give an error message nor does it prompt the user; it just sits there waiting for the user to do the “right thing.” The difficulty could have been avoided by displaying the list of one item with that item already selected and highlighted, thus providing a useful default selection and allowing the Select button to be active from the start.

It is a small thing in a design, but it can be so nice to have the cursor just where you need it when you arrive at a dialogue box or window in which you have to work. As a designer, you can save users the work and irritation of extra physical actions, such as an extra mouse click before typing, by providing appropriate default cursor location, for example, in a data field or text box, or within the user interface object where the user is most likely to work next.

Figure 22-36 contains a dialogue box for planning events in a calendar system. Designers chose to highlight the frequency of occurrences of the event in terms of the number of weeks, in the Weekly section. This might be a little helpful to users who will type a value into the “increment box” of this data field, but users are just as likely to use the up and down arrows of the increment box to set Values, in which case the default highlighting does not help. Further evaluation will be necessary to confirm this, but it is possible that putting the default cursor in the Effective Date field at the bottom might be more useful.

Supporting human memory limitations in cognitive affordances

Earlier we elaborated on the concept of human memory limitations in human–computer interaction. This section is the first of several in which we get to put this knowledge to work in specific interaction design situations.

Provide reminders to users of what they are doing and where they are within the task flow. Post important parts of the task context, parameters the user must keep track of within the task, so that the user does not have to commit them to memory.

For cases where choices, alternatives, or possible data entry values are known, designing to use recognition over recall means allowing the user to select an item from among choices rather than having to specify the choice strictly from memory. Selection among presented choices also makes for more precise communication about choices and data values, helping avoid errors from wording variations and typos.

One of the most important applications of this guideline is in the naming of files for an operation such as opening a file. This guideline says that we should allow users to select the desired file name from a directory listing rather than requiring the user to remember and type in the file name.

To begin with, the cognitive affordance shown in Figure 22-37 describing the desired user action is too vague and open-ended to get any kind of specific input from a user. What if the user does not know the exact model number and what kind of description is needed? This illustrates a case where it would be better to use a set of hierarchical menus to narrow down the category of the product in mind and then offer a list in a pull-down menu to identify the exact item.

In Figure 22-38 we show a very early Save As dialogue box in a Microsoft Office application. At the top is the name of the current folder and the user can navigate to any other folder in the usual way. But it does not show the names of files in the current folder.

This design precedes modern versions that show a list of existing files in this current folder, as shown in Figure 22-39.

This list supports memory by showing the names of other, possibly similar, files in the folder. If the user is employing any kind of implicit file-naming convention, it will be evident, by example, in this list.

For example, if this folder is for letters to the IRS and files are named by date, such as “letter to IRS, 3-30-2010,” the list serves as an effective reminder of this naming convention. Further, if the user is saving another letter to the IRS here, dated 4-2-2010, that can be done by clicking on the 3-30-2010 letter and getting that name in the File name: text box and, with a few keystrokes, editing it to be the new name.

In some applications, moving from one subtask to another requires users to remember key data or other related information and bring it to the second subtask themselves. For example, suppose a user selects an item of some kind during a task and then wishes to go to a different part of the application and apply another function to which that item is an input. We have experienced applications that required us to remember the item ourselves and re-enter it as we arrived at the new functionality.

Be suspicious of usage situations that require users to write something down in order to use it somewhere else in the application; this is a sign of an opportunity to support human memory better in the design. As an example, consider a user of a Calendar Management System who needs to reschedule an appointment. If the design forces the user to delete the old one and add the new one, the user has to remember details and re-enter them. Such a design does not follow this guideline.

Voice menus, such as telephone menus, are more difficult to remember because there is no visual reminder of the choices as there is in a screen display. Therefore, we have to organize and state menu choices in a way to reduce human memory load.

For example, we can give the most likely or most frequently used choices first because the deeper the user goes into the list, the more previous choices there are to remember. As each new choice is articulated, the user must compare it with each of the previous choices to determine the most appropriate one. If the desired item comes early, the user gets cognitive closure and does not need to remember the rest of the items.

Cognitive directness in cognitive affordances

Cognitive directness is about avoiding mental transformations for the user. It is about what Norman (1990, p. 23) calls “natural mapping.” A good example from the world of physical actions is a lever that goes up and down on a console but is used to steer something to the left or the right. Each time it is used, the user must rethink the connection, “Let us see; lever up means steer to the left.”

A classic example of cognitive directness, or the lack thereof, in product design is in the arrangement of knobs that control the burners of a cook top. If the spatial layout of the knobs is a spatial map to the burner configuration, it is easy to see which knob controls which burner. Seems easy, but many designs over the years have violated this simple idea and users have frequently had to reconstruct their own cognitive mapping.

Support user cognitive affordance content understanding by presenting choices and information in cognitively direct expressions rather than in some kind of encoding that requires the user to make a mental translation. The objective of this guideline is to help the user avoid an extra step of translation, resulting in less cognitive effort and fewer errors.

For a user to rotate a two-dimensional graphical object, there are two directions: clockwise and counterclockwise. While “Rotate Left” and “Rotate Right” are not technically correct, they might be better understood by many than “Rotate CW” and “Rotate CCW.” A better solution might be to show small graphical icons, circles with an arc arrow over the top pointing in clockwise and counterclockwise directions.

Macromedia Dreamweaver™ is an application used to set up simple Web pages. It is easy to use in many ways, but the version we discuss here contains an interesting and definitive example of cognitive indirectness in its design. In the right-hand side pane of the site files window in Figure 22-40 are local files as they reside on the user’s PC.

The left-hand side pane of Figure 22-40 shows a list of essentially the same files as they reside on the remote machine, the Website server. As users interact with Dreamweaver to edit and test Web pages locally on their PCs, they upload them periodically to the server to make them part of the operational Website. Dreamweaver has a convenient built-in “ftp” function to implement this file transfer. Uploading is accomplished by clicking on the up-arrow icon just above the Local site label and downloading uses the down arrow.

The problem comes in when users, weary from editing Web pages, click on the wrong arrow. The download arrow can bring the remote copy of the just-edited file into the PC. Because the ftp function replaces files with the same name as new ones arriving without asking for confirmation, this feature is dangerous and can be costly. Click on the wrong icon and you can lose a lot of work.

“Uploading” and “downloading” are system-centered, not usage-centered, terms and have arbitrary meaning about the direction of data flow, at least to the average non-systems person. The up- and down-arrow icons do nothing to mitigate this poor mapping of meaning. Because the sets of files are on the left-hand side and right-hand side, not up and down, often users must stop and think about whether they want to transfer data left or right on the screen and then translate it into “up” or “down.” The icons for transfer of data should reflect this directly; a left arrow and a right arrow would do nicely. Furthermore, given that the “upload” action is the more frequent operation, making the corresponding arrow (left in this example) larger provides a better cognitive (and physical affordance in terms of click target size) affordance.

In Figure 22-41 you can see a photo of the heater control in a car. It looks extremely simple; just turn the knob.

However, to a new user the interaction here could be surprising. The control looks as though you grab the knob and the whole thing turns, including the numbers on its face. However, in actuality, only the outside rim turns, moving the indicator across the numbers, as seen in the sequence of Figure 22-42.

So, if the user’s mental model of the device is that rotating the knob clockwise slows down the heater fan, he or she is in for a surprise. The clockwise rotation moves the indicator to higher numbers, thus speeding up the heater fan. It can take users a long time to get used to having to make that kind of a cognitive transformation.

Complete information in cognitive affordances

Support the user’s understanding of cognitive affordances by providing complete and sufficient expression of meaning, to disambiguate, make more precise, and clarify. For each label, menu choice, and so on the designer should ask “Is there enough information and are there enough words used to distinguish cases?”

The expression of a cognitive affordance should be complete enough to allow users to predict the consequences of actions on the corresponding object.

Completeness helps the user distinguish alternatives without having to stop and contemplate the differences. Complete expressions of cognitive affordance meaning help avoid errors and lost productivity due to error recovery.

Some people think button labels, menu choices, and verbal prompts should be terse; no one wants to read a paragraph on a button label. However, reasonably long labels are not necessarily bad and adding words can add precision. Often a verb plus a noun are needed to tell the whole story. For example, for the label on a button controlling a step in a task to add a record in an application, consider using Add Record instead of just Add.

As another example of completeness in labeling, for the label on a knob controlling the speed of a machine, rather than Adjust or Speed, consider using Adjust Speed or maybe even Clockwise to increase speed, which includes information about how to make the adjustment.

If you cannot reasonably get all the necessary information in the label of a button or tab or link, for example, consider using a fly-over pop up to supplement the label with more information.

In Figure 22-43 is a message from Microsoft Word that has given us pause more than once. We think we know what button we should click but we are not entirely confident and it seems as though it could have a significant effect on our file.

Figure 22-44 contains a message dialogue box from Microsoft Outlook that can strike fear into the heart of a user. It just does not give enough information about the consequences of either choice presented. If the user exits anyway, does it still send the outstanding messages or do they get lost? To make matters worse, there is undue pressure that the system will take control and exit if the user cannot decide in the next 8 seconds.

Few things are as frustrating to users as a dialogue box or other user interface object presenting choices that do not include the one alternative the users really needs. No matter what the user does next, it will not turn out well.

Usage centeredness in cognitive affordances

We find that many of our students do not understand what it means to be user centered or usage centered in interaction design. Mainly it means to use the vocabulary and concepts of the user’s work context rather than the vocabulary and context of the system. This difference between the language of the user’s work domain and the language of the system is the essence of “translation” in the translation part of the Interaction Cycle.

As designers, we have to help users make that translation so they do not have to encode or convert their work domain vocabulary into the corresponding concepts in the system domain. The story of the toaster in Chapter 21 is a good example of a design that fails to help the user with this translation from task or work domain language to system control language. The conveyor belt speed control is labeled with system language, “Faster” and “Slower” instead of being labeled in terms of the work domain of toast making, “Lighter” and “Darker.”

Avoiding errors with cognitive affordances

The Japanese have a term, “poka-yoke,” that means error proofing. It refers to a manufacturing technique to prevent parts of products from being made, assembled, or used incorrectly. Most physical safety interlocks are examples. For instance, interlocks in most automatic transmissions enforce a bit of safety by not allowing the driver to remove the key until the transmission is in park and not allowing shifting out of park unless the brake is depressed.

Anticipating user errors in the workflow, of course, stems back to contextual inquiry and contextual analysis, and concern for avoiding errors continues throughout requirements, design, and UX evaluation.

Consider the context of a shower in which there are two bottles, one for shampoo and one for conditioner, examples of which you can see in Figure 22-45. But the problem is that one cannot see them well enough to know which is which. The important distinguishing labels, for shampoo and for conditioner, are “hidden” within a lot of other text and are in such a small font as to be illegible without focused attention, especially with soap in the eyes.

So users sometimes add their own (user-created) affordances by, in this case, adding labels on the tops of the bottles to tell them apart in the shower, as shown in Figure 22-46.

You can see, in Figure 22-47, an example of a kind of shampoo bottle design that would have avoided the problem in the first place.

In this clever design, the shampoo, the first one you need, is right-side up and the labeling on the conditioner bottle, the next one you need, is printed so that you stand the bottle “upside down.”

This guideline has three parts: one to disable the choices, the second to show the user that they are disabled, and the third to explain why they are disabled.

Help users avoid errors within the task flow by disabling choices in buttons, menus, and icons that are inappropriate at a given point in the interaction.

As a corollary to the previous guideline, support user awareness of unavailable choices by making cognitive affordances for those choices appear unavailable, in addition to being unavailable. This is done by making some adjustment to the presentation of the corresponding cognitive affordance.

One way is to remove the presentation of that cognitive affordance, but this leads to an inconsistent overall display and leaves the user wondering where that cognitive affordance went. The conventional approach is to “gray out” the cognitive affordance in question, which is universally taken to mean the function denoted by the cognitive affordance still exists as part of the system but is currently unavailable or inappropriate.

If a system operation or function is not available or not appropriate, it is usually because the conditions for its use are not met. One of the most frustrating things for users, however, is to have a button or menu choice grayed out but no indication about why the corresponding function is unavailable. What can you do to get this button un-grayed? How can you determine the requirements for making the function available?

We suggest an approach that would be a break with traditional GUI object behavior but that could help avoid that source of user frustration. Clicking on a grayed-out object could yield a pop up with this crucial explanation of why it is grayed out and what you must do to create the conditions to activate the function of that user interface object.

In a document retrieval system, one of the user tasks is adding new keywords to existing documents, documents already entered into the system. Associated with this task is a text box for typing in a new keyword and a button labeled Add Keyword. The user was not sure whether to click on the Add Keyword button first to initiate that task or to type the new keyword and then click on Add Keyword to “put it away.”

A user tried the former and nothing happened, no observable action and no feedback, so the user deduced that the proper sequence was to first type the keyword and then click the button. No harm done except a little confusion and lost time. However, the same glitch is likely to happen again with other users and with this user at a later time.

The solution is to gray out the Add Keyword button to show when it does not apply, making it obvious that it is not active until a keyword is entered. Per our suggestion earlier, we could add an informative pop-up message that appears when someone clicks on the grayed-out button to the effect that the user must first type something into the new keyword text box before this button becomes active and allows the user to commit to adding that keyword.

Cognitive affordances for error recovery

As much as possible, provide ways for users to back out of error situations by “undo” actions. Although they are more difficult to implement, multiple levels of undo and selective undo among steps are more powerful for the user.

Users learn about errors through error messages as feedback, which is considered in the assessment part of the Interaction Cycle. Feedback occurs as part of the system response (Chapter 21). A system response designed to support error recovery will usually supplement the feedback with feed-forward, a cognitive affordance here in the translation part of the Interaction Cycle to help users know what actions or task steps to take for error recovery.

Cognitive affordances for modes

Modes are states where actions have different meanings than the same actions in different states. The simplest example is a hypothetical email system. When in the mode of managing email files and directories, the command Ctrl-S means Save. However, when you are in the mode of composing an email message, Ctrl-S means Send. This design, which we have seen in the “old days,” is an invitation to errors. Many a message has been sent prematurely out of the habit of doing a Ctrl-S periodically out of habit to be sure everything is saved.

The problem with most modes in interaction design is the abrupt change of the meanings of user actions. It is often difficult for users to shift focus between modes and, when they forget to shift as they cross modal boundaries, the outcomes can be confusing and even damaging. It is a kind of bait and switch; you just get your users comfortable in doing something one way and then change the meaning of the actions they are using.

Modes within interaction designs can also work strongly against experienced users, who move fast and habitually without thinking much about their actions. In a kind of “UX karate,” they get leaning one way in one mode and then their own usage momentum gets used against them in the other mode.

If it is possible to avoid modes altogether, the best advice is to do so.

Think about digital watches. Enough said.

If modes become necessary in your interaction design, the next-best advice is to be sure that users are aware of each mode and avoid confusion across modes.

Not all modes are bad. The use of modes in design can represent a case for interpreting design guidelines, not just applying them blindly. The guideline to avoid modes is often good advice because modes tend to create confusion. But modes can also be used in designs in ways that are helpful and not at all confusing.

An example of a good mode needed in a design comes from audio equalizer controls on the stereo in a particular car. As with most radio equalizers, there are choices of fixed equalizer settings, often called “presets,” including audio styles such as voice, jazz, rock, classical, new age, and so on.

However, because there is no indication in the radio display of the current equalizer setting, you have to guess or have faith. If you push the Equalizer button to check the current setting, it actually changes the setting and then you have to toggle back through all the values to recover the original setting. This is a non-modal design because the Equalizer button means the same thing every time you push it. It is consistent; every button push yields the same result: toggling the setting.

It would be better to have a slightly moded design so that it starts in a “display mode,” which means an initial button push causes it to display the current setting without changing the setting so that you can check the equalizer setting without disturbing the setting itself. If you do wish to change the setting, you push the same Equalizer button again within a certain short time period to change it to the “setting mode” in which button pushes will toggle the setting. Most such buttons behave in this good moded way, except in this particular car.

Human working memory loads in task structure

The most important way to support human memory limitations within the design of task structure is to provide task closure as soon and as often as possible; avoid interruption and stacking of subtasks. This means “chunking” tasks into small sequences with closure after each part.

While it may seem tidy from the computer science point of view to use a “preorder” traversal of the hierarchical task structure, it can overload the user’s working memory, requiring stacking of context each time the user goes to a deeper level and “popping” the stack, or remembering the stacked context, each time the user emerges up a level in the structure.

Interruption and stacking occur when the user must consider other tasks before completing the current one. Having to juggle several “balls” in the air, several tasks in a partial state of completion, adds an often unnecessary load to human memory.