Design task structure for flexibility and efficiency

Support user needs for flexibility within the logical task flow by providing alternative ways to do tasks. Meet user needs for efficiency with shortcuts for frequently performed tasks and provide support for task thread continuity, supporting the most likely next step.

One of the most striking observations during task-based UX evaluation is the amazing variety of ways users approach task structure. Users take paths never imagined by the designers.

There are two ways designers can become attuned to this diversity of task paths. One is through careful attention to multiple ways of doing things in contextual inquiry and contextual analysis and the other is to leverage observations of such user behavior in UX evaluation. Do not just discount observations of users gone “astray” as “incorrect” task performance; try to learn about valuable alternative paths.

No one wants to have to make too many mouse clicks or other user actions to complete a task, especially in complex task sequences (Wright, Lickorish, & Milroy, 1994). For efficiency within frequently performed tasks, experienced users especially need shortcuts, such as “hot key” (or “accelerator key”) alternatives for other more complicated action combinations, such as selecting choices from pull-down menus.

Keyboard alternatives are particularly useful in tasks that otherwise require keyboard actions such as form filling or word processing; staying within the keyboard for these “commands” avoids having the physical “switching” actions required for moving between the keyboard and mouse, for example, two physically different devices.

Grouping for task efficiency

Under the topic of layout and grouping to control content and meaning complexity, we grouped related things to make their meanings clear. Here we advocate grouping objects and other things related to the same task or user work activity as a means of conveniently having the needed components for a task at hand. This kind of grouping can be accomplished spatially with screen or other device layout or it can be manifest sequentially, as in a sequence of menu choices.

As Norman (2006) illustrates, in a taxonomic “hardware store” organization, hammers of all different kinds are all hanging together and all different kinds of nails are organized in bins somewhere else. But a carpenter organizes his or her tools so that the hammer and nails are in proximity because the two are used together in work activities.

Grouping user interface objects such as buttons, menus, value settings, and so on creates the impression that the group comprises a single focus for user action. If more is needed for that task goal, each requiring separate actions, do not group the objects tightly together but make clear the separate objectives and the requirement for separate actions.

A dialogue box from a paper prototype of a Ticket Kiosk System is shown in Figure 22-49.

It contains two objectives and two corresponding objects for value settings by the user—proximity of the starting time of a movie and the distance of the movie theater from the kiosk. Most of the participants who used this dialogue box as part of a ticket-buying task made the first setting and clicked on Continue, not noticing the second component. The solution that worked was to separate the two value-setting operations into two dialogue boxes, forcing a separation of the focus and linearizing the two actions.

Task thread continuity: Anticipating the most likely next step or task path

Task thread continuity is a design goal relating to task flow in which the user can pursue a task thread of possibly many steps without an interruption or “discontinuity.” It is accomplished in design by anticipating most likely and other possible next steps at any point in the task flow and providing, at hand, the necessary cognitive, physical, and functional affordances to continue the thread.

The likely next steps to support can include tasks or steps the user may wish to take but which are not necessarily part of what designers envisioned as the “main” task thread. Therefore, these various task directions might not be identified by pure task analysis, but are steps that a practitioner or designer might see in contextual inquiry while watching users perform the tasks in a real work activity context. Effective observation in UX evaluation also can reveal diversions, branching, and alternative task paths that users associate with the main thread.

Attention to task thread continuity is especially important when designing the contents of context menus, right-click menus associated with objects or steps in tasks. It is also important when designing message dialogue boxes that offer branching in the task path, which is when users need at hand other possibilities associated with the current task.

Probably the most defining example of task thread continuity is seen in a message dialogue box that describes a problematic system state and suggests one or more possible courses of action as a remedy. But then the user is frustrated by a lack of any help in getting to these suggested new task paths.

Task thread continuity is easily supported by adding buttons that offer a direct way to follow each of the suggested actions. Suppose a dialogue box message tells a user that the page margins are too wide to fit on a printed page and suggests resetting page margins so that the document can be printed. It is enormously helpful if this guideline is followed by including a button that will take the user directly to the page setup screen.

Designers of information retrieval systems sometimes see the task sequence of formulating a query, submitting it, and getting the results as closure on the task structure, and it often is. So, in some designs, the query screen is replaced with the results screen. However, for many users, this is not the end of the task thread.

Once the results are displayed, the next step is to assess the success of the retrieval. If the query is complex or much has happened since the query was submitted, the user will need to review the original query to determine whether the results were what was expected. The next step may be to modify the query and try again. So this often simple linear task can have a thread with larger scope. The design should support these likely alternative task paths.

Designers of successful online shopping sites such as Amazon.com have figured out how to make it convenient for shoppers by providing for likely next steps (seeing and then buying) in their shopping tasks. They support convenience in ordering with the ubiquitous Buy it now or Add to cart buttons. They also support product research. If a potential customer shows interest in a product, the site quickly displays other products and accessories that go with it or alternative similar products that other customers have bought.

In early Microsoft Office applications the Save As dialogue box did not contain the icon for creating a new folder (the next to the right-hand icon at the top of the dialogue box in Figure 22-50). Eventually, designers realized that as part of the “Save As” task, users had to think about where to put the file and, as part of that planning for organizing their file structures, they often needed to create new folders to modify or expand the current file structure.

Early users had to back out of the “Save As” task and go to Windows Explorer, navigate to the proper context, create the folder, and then return to the Office application and do the “Save As” all over again. By including the ability to create a new folder within the Save As dialogue box, this likely next step was accommodated directly.

In some cases, the most likely next step is so likely that task thread continuity is supported by adding a slight amount of automation and doing the step for the user. The following example is one such case.

For frequent users of Word, the Outline view helps organize material within a document. You can use the Outline view to move quickly from where you are in the document to another specific location. In the Outline view, you get a choice of the number of levels of outline to be shown. It is common for users to want to keep this Outline view level setting at a high level, affording a view of the whole outline. So, for many users, the most likely-used setting would be that high setting. Many users rarely even choose anything else.

Regardless of any user’s level preferences, if a user goes to the Outline view it is because he or she wants to see and use the outline. But the default level setting in Word’s Outline view is the only setting that really is not an outline. The default Word Outline view, Show all levels, is a useless mash-up of outline parts and non-outline text. As a default this setting is the least useful for anyone.

Every time users launch a Word document, they face that annoying Outline view setting. Even once you have shown your preference by setting the level, the system inevitably strays away from that setting during editing, forcing you to reset it frequently. Frequent users of Word will have made this setting thousands of times over the years. Why cannot Word help users by saving the settings they use so consistently and have set so often?

Designers might argue that they cannot assume they know what level a user needs so they follow the guideline to “give the user control.” But why design a default that guarantees the user will have to change it instead of something that might be useful to at least some users some of the time? Why not detect the highest level present in the document and use that as a default? After all, the user did request to see the outline.

Earlier we described an example in which the user had to select an item from a dialogue box list of choices, even though there was only one item in the list. Our point there was that preselecting the item for the user made for a useful default.

The same idea applies here: When there is only one choice, the designer can support user efficiency through task thread continuity by assuming the most likely next action to be selecting that only choice and making the selection in advance for the user. An example of this comes from Microsoft Outlook.

When an Outlook user selects Rules and Alerts from the Tools menu and clicks on the Run Rules Now button, the Run Rules Now dialogue box appears. In cases where there is only one rule, it is highlighted in the display, making it look selected. However, be careful, that rule is not selected; the highlighting is a false affordance.

Look closely and you see that the checkbox to its left is unchecked and that is the indication of what is selected. The result is the Run Now button is grayed out, causing some users to pause in confusion about why the rule cannot now be run. Most such users figure it out eventually, but lose time and patience in the confusion. This UX glitch can be avoided by preselecting this only choice as the default.

Not undoing user work

Do you not hate it when you fill out part of a form and go away to get more information or to attend temporarily to something else and, when you come back, you return to an empty form? This usually comes from lazy programming because it takes some buffering to retain your partial information. Do not do this disservice to your users.

It helps users keep track of state information, such as user preferences, that they set in the course of usage. It is exasperating to have to reset preferences and other state settings that do not persist across different work sessions.

It would help users a lot if Windows could be a little bit more helpful in keeping track of the focus of their work, especially keeping track of where they have been working within the directory structure. Too often, you have to reestablish your work context by searching through the whole file directory in a dialogue box to, say, open a file.

Then, later, if you wish to do a Save As with the file, you may have to search that whole file directory again from the top to place the new file near the original one. We are not asking for built-in artificial intelligence, but it would seem that if you are working on a file in a certain part of the directory structure and want to do a Save As, it is very likely that the file is related to the original and, therefore, needs to be saved close to it in the file structure.

Keeping users in control

Sometimes, although users are still actually in control, interaction dialogue can make users feel as though the computer is taking control. Although designers may not give a second thought to language such as “You need to answer your email,” these words can project a bossy attitude to users. Something such as “You have new email” or “New email is ready for reading” conveys the same meaning but does so in a way that helps users feel that they are not being commanded to do something; they can respond whenever they find it convenient.

More bothersome to users and more detrimental to productivity is a real loss of user control. You, the designer, may think you know what is best for the user, but you will do best to avoid the temptation of being high handed in matters of control within interaction. Few kinds of user experience give rise to anger in users than a loss of control. It does not make them behave the way you think they should; it only forces them to take extra effort to work around your design.

One of the most maddening examples of loss of user control we have experienced comes from EndNote™, an otherwise powerful and effective bibliographic support application for word processing. When EndNote is used as a plug-in to Microsoft Word, it can be scanning your document invisibly for actions to take with regard to your bibliographic citations.

If an action is deemed necessary, for example, to format an in-line citation, EndNote often arbitrarily takes control away from a user doing editing and moves the cursor to the location where the action is needed, often many pages away from the focus of attention of the user and usually without any indication of what happened. At that point, users are probably not interested in thinking about bibliographic citations but are more concerned with their task at hand, such as editing. All of a sudden control is jerked away and the working context disappears. It takes extra cognitive energy and extra physical actions to get back to where the user was working. The worst part is that it can happen repeatedly, each time with an increasingly negative emotional user reaction.

Direct manipulation and natural interaction control

From the earliest computer usage, users have given “commands” to computers to get them to perform functions. Invoking a computer function “by command” is an indirect way to get something done by asking the computer to do it for you. In many kinds of applications there is a more direct way—essentially to do it yourself through direct manipulation (Shneiderman, 1983; Hutchins, Hollan, & Norman, 1986).

The introduction of direct manipulation, the essence of GUIs, as an interaction technique (Shneiderman, 1983) has been one of the most important in terms of designing interaction to be natural for human users. Instead of syntactic commands, operations are invoked by user actions manipulating user interface objects.

For example, instead of typing “del my_file.doc,” one might delete the file by clicking on and dragging the file icon to the “trashcan” object. Unlike the case in command-driven interaction, direct manipulation features continuous representation, usually visual, of interaction objects. As Shneiderman, who gets credit for identifying and characterizing direct manipulation as an interaction style, puts it, a key characteristic is “rapid incremental reversible operations whose impact on the object of interest is immediately visible” (Shneiderman, 1982, p. 251; 1983).

Users can perform tasks easily by pointing to visual representations of familiar objects. They can see results immediately and visually, for example, a file going into a folder. The direct manipulation interaction style is easy to learn and encourages exploration. Direct manipulation goes hand in hand with metaphors, like a stack of cards for addresses. Users apply direct manipulation actions to the objects of the metaphor, for example, moving cards within a stack. And, of course, the visual thinking and actions of direct manipulation apply beyond metaphors to manipulating objects in three dimensions as in virtual and augmented reality applications.

One way that the notion of direct manipulation enters into the design of physical products such as radios and television sets is by way of the concept of physicality. If controls for these physical devices, such as volume and tuning controls, are implemented with real knobs, users can operate them by physically grasping and turning them. This is literally a kind of direct manipulation.

Take adding an appointment to a computer-based calendar as an example. We illustrate the command-driven approach with the following task sequence. The user navigates to the desired day within the calendar and clicks on the time slot to select it. Then clicking the Add appointment button brings up a dialogue box in which the user types the text in one or more fields describing the appointment.

Then clicking on OK or Save appointment dismisses the dialogue box, essentially asking the computer to store the appointment. In the direct manipulation paradigm, the calendar looks and feels much like a paper calendar. The user types the appointment information directly into the time slot on the calendar, just as one might write on a paper calendar with a pencil. There is no need to ask for the appointment to be saved; anything you “write” in the calendar stays there, just as it does on a paper calendar.

Do not trap a user in an interaction. Always allow a way for users to escape if they decide not to proceed after getting part way into a task sequence. The usual way to design for this guideline is to include a Cancel, usually as a dialogue box button.

Sensing objects to manipulate

The “sensing user interface object” portion of the physical actions part is about designing to support user sensory, for example, visual, auditory, or tactile, needs in locating the appropriate physical affordance quickly in order to manipulate it. Sensing for physical actions is about presentation of physical affordances, and the associated design issues are similar to those of the presentation of cognitive affordances in other parts of the Interaction Cycle, including visibility, noticeability, findability, distinguishability, discernability, sensory disabilities, and presentation medium.

Make objects to be manipulated visible, discernable, legible, noticeable, and distinguishable. When possible, locate the focus of attention, the cursor, for example, near the objects to be manipulated.

One of us has a stereo with a CD player with controls, such as for play and stop, that are black buttons embossed with black icons. This black-on-black motif is cool looking but has a negative impact on usability. You can see the raised embossing of the icons in good light, but sometimes you like to hear your music in a low-light ambiance, a condition that makes it very difficult to see the icons.

Most people know that you should push the play button when you want to play a CD, but in low light it is difficult to tell where that button is on the plain black front of the CD player. This is definitely a case of the sensory design not supporting the ability to locate the object of an intended physical action.

Sensing objects during manipulation

Not only is it important to be able to sense objects statically to initiate physical actions but users need to be able to sense the cursor and the physical affordance object dynamically to keep track of them during manipulation. As an example, in dragging a graphical object, the user’s dynamic sensory needs are supported by showing an outline of the graphical object, aiding its placement in a drawing application.

As another very simple example, if the cursor is the same color as the background, the cursor can disappear into the background while moving it, making it difficult to judge how far to move the mouse back to get it visible again.

Awkwardness and physical disabilities

One of the easiest aspects of designing for physical actions is avoiding awkwardness. It is also one of the easiest areas in which to find existing problems in UX evaluation.

Issues of physical awkwardness are often about time and energy expended in physical motions. The classic example of this issue is a user having to alternate constantly among multiple input devices such as between a keyboard and a mouse or between either device and a touchscreen.

This device switching involves constant “homing” actions that require time-consuming and effortful distraction of cognitive focus and visual attention. Keyboard combinations requiring multiple fingers on multiple keys can also be awkward user actions that hinder smooth and fast interaction.

Not all human users have the same physical abilities—range of motion, fine motor control, vision, or hearing. Some users are innately limited; some have disabilities due to accidents. Although in-depth coverage of accessibility issues is beyond our scope, accommodation of user disabilities is an extremely important part of designing for the physical actions part of the Interaction Cycle and must at least be mentioned here.

Manual dexterity and Fitts’ law

Design issues related to Fitts’ law are about movement distances, mutual object proximities, and target object size. Performance is reckoned in terms of both time and errors. In a strict interpretation, an error would be clicking anywhere except on the correct object. A more practical interpretation would limit errors to clicking on incorrect objects that are nearby the correct object; this is the kind of error that can have a more negative effect on the interaction. This discussion leads to the following guidelines.

The bottom line about sizes cursor movement targets is simple: small objects are harder to click on than large ones. Give your interaction objects enough size, both in cross section for accuracy in the cursor movement direction and in the depth to support accurate termination of movement within the target object.

Avoid fatigue, and slow movement times. Large movement distances require more time and can lead to more targeting errors. Short distances between related objects will result in shorter movement times and fewer errors.

Avoid erroneous selection that can be caused by close proximity of target objects to non-target objects.

A software drawing application has a very large number of functions, most of which are accessible via small icons in a very crowded tool bar. Each function can also be invoked by another way (e.g., a menu choice), and our observations tell us that users mainly use the tool bar icons for familiar and frequently used functions.

As a result, they do not usually have trouble figuring out which icon to click on. If it is not a familiar function, they do not use the icons. The problem is about what happens when they do use the tool icons because there are so many icons, they are small, and they are crowded together. This, combined with the fast actions of experienced users, leads to clicking on the wrong icon more often than users would like.

Constraining physical actions to avoid physical overshoot errors

Just as in the case of cursor movement, other kinds of physical actions can be at risk for overshoot, extending the movement beyond what was intended. This concept is best illustrated by the hair dryer switch example that follows.

Suppose you are using the hair dryer, let us say, on the low setting. To move the hair dryer switch takes a certain threshold pressure to overcome initial resistance. Once in motion, however, unless the user is adept at reducing this pressure instantly, the switch can move beyond the intended setting.

A strong detent at each switch position can help prevent the movement from going too far, but it is still easy to push the switch too far, as the photo of a hair dryer switch in Figure 22-53 illustrates. Starting in the Low position and pushing the switch toward Off, the switch configuration makes it easy to move accidentally beyond Off over to the High setting.

This is physical overshoot and is easy to prevent with a switch design that goes directly from High to Low and then to Off in a logical progression. Having the Off position at one end of the physical movement is a kind of physical constraint or boundary condition that allows you to push the switch to Off firmly and quickly without demanding a careful touch or causing worry of overshooting.

The rocker switch design in Figure 22-54 is a bit better with respect to physical overshoot because it is easier to control the position of a rocker switch as it is being moved. Still, a design with Off at one end of the movement would be a more certain design for preventing physical overshoot. It is probably easier to manufacture a switch with the neutral Off position in the middle.

The automatic transmission shifter of a pickup truck shown in the lower part of Figure 22-55 is an example of a design where physical overshoot is common. You can see the shift control configuration of the truck with the common linear progression of gears from low to high. Most of the time this is adequate design, but when you are coming down a long hill, you might want to downshift to maintain the speed limit without wearing out the brakes.

However, because the shifting movement is linear, when you pull that lever down from D, it is too easy to overshoot third gear and end up in second. The result of this error becomes immediately obvious from the screaming of the engine at high RPM.

This downshifting overshoot is remedied by the gear shifting pattern of a Toyota Sienna van, shown in Figure 22-56. The gear labeled 4-D is fourth, or high, gear that includes an automatic overdrive for highway travel.

When you shift down to third gear, the movement is constrained physically by a “template” overlaying the shifting lever and overshoot is prevented. It is very unlikely that a user will accidentally shift into second gear because that requires a conscious extra action of moving the lever to the right and then further down.

Finally, Figure 22-57 shows the gear-shifting pattern for a Winnebago View, which is a very small RV built on a Mercedes-Benz Sprinter chassis and drive train. It has a “tilt shift,” which means that when the transmission is in drive, you can access lower gears successively by tilting the shift lever to the left and you can shift back up to higher gears by shifting the lever to the right. This is probably the easiest to use and safest of all options in terms of the risk of downshifting overshoot.

Haptics and physicality

Haptics is about the sense of touch and physical grasping, and physicality is about real physical interaction using real physical devices, such as real knobs and levels, instead of “virtual” interaction via “soft” devices.

The BMW iDrive idea seemed so good on paper. It was simplicity in itself. No panels cluttered with knobs and buttons. How cool and forward looking. Designers realized that drivers could do anything via a set of menus. But drivers soon realized that the controls for everything were buried in a maze of hierarchical menus. No longer could you reach out and tweak the heater fan speed without looking. Fortunately, knobs are now coming back in BMWs.

Here is an email from our friend, Roger Ehrich, from back in 2002, only slightly edited:

 Hey Rex, since our microwave was about 25 years old, we worried about radiation leakage, so we reluctantly got a new one. The old one had a knob that you twisted to set the time, and a START button that, unlike in Windows, actually started the thing.

 The new one had a digital interface and Marion and I spent over 10 minutes trying to get it to even turn on, but we got nothing but an error message. I feel you should never get an error message from an appliance! Eventually we got it to turn on. The sequence was not complicated, but it will not tolerate any variation in user behavior. The problem is that the design is modal, some buttons being multi-functional and sequential. A casual user like me will forget and get it wrong again. Better for me to take my popcorn over to a neighbor who remembers what to do. Anyway, here’s to the good old days and the timer knob.

– Regards, Roger

Figure 22-58 shows a photo of radio controls in a car.

There is no knob for tuning; tuning is done by pushing the up and down arrows on the left-hand side. At least there is a real volume control knob but it is small with almost no depth, making it a poor physical affordance for grasping, even with slender fingertips.

As you try to get a better grip, it is easy to push it inwardly unintentionally, causing the knob and what it controls to become modal, going away from being volume control and becoming a knob to control equalizer settings. To get back to the knob being a volume control, you have to wait until the equalizer mode times out or you must toggle through all the equalizer settings back out to the volume control mode—all, of course, without taking your eyes off the road.

In contrast, Figure 22-59 is a photo of the radio and heater controls of a pickup truck.

Still no tuning knob; too bad. But the large and easily grasped outside ring of the volume control knob is a joy to use and it is not doubled up with any other mode. Also note the heater control knobs below the radio. Again, the physicality of grabbing and adjusting these knobs gives great pleasure on a cold winter morning.

Feedback visibility

Obviously feedback cannot be effective if it cannot be seen or heard when it is needed.

It is the designer’s job to be sure each instance of feedback is visible when it is needed in the interaction.

Feedback noticeability

When needed feedback exists and is visible, the next consideration is its noticeability or likelihood of being noticed or sensed. Just putting feedback 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 feedback should come to users’ attention without users seeking it. The primary design factor in this regard is location, putting feedback within the users’ focus of attention. It is also about contrast, size, and layout complexity and their effect on separation of feedback from the background and from the clutter of other user interface objects.

A pop-up dialogue box that appears directly within the user’s focus of attention in the middle of the screen is much more noticeable than a message or status line at the top or bottom of the screen.

Feedback legibility

Text legibility is about being discernable, not about its content being understandable. Font size, font type, color, and contrast are the primary relevant design factors.

Feedback presentation complexity

Support user needs to locate and be aware of feedback by controlling layout complexity of user interface objects. Screen clutter can obscure needed feedback and make it difficult for users to find.

Feedback timing

Support user needs to notice feedback with appropriate timing of appearance or display of feedback. Present feedback promptly and with adequate persistence, that is, avoid “flashing.”

A local software company asked us to inspect one of their software tools. In this tool, users are restricted to certain subsets of functionality based on privileges, which in turn are based on various key work roles. A UX problem with a large impact on users arose when users were not aware of which parts of the functionality they were allowed to use.

As the result of a designer assumption that each user would know their privilege-based limitations, users were allowed to navigate deeply into the structure of tasks that they were not supposed to be performing. They could carry out all the steps of the corresponding transactions but when they tried to “commit” the transaction at the end, they were told they did not have the privileges to do that task and were blocked and their time and effort were wasted. It would have been easy in the design to help users realize much earlier that they were on a path to an error, thereby saving user productivity.

Feedback presentation consistency

Feedback presentation medium

Consider appropriate alternatives for presenting feedback.

Audio can be more effective than visual media to get users’ attention in cases of a heavy task load or heavy sensory work load. Audio is also an excellent alternative for vision-impaired users.

Clarity of feedback

Use precise wording and carefully chosen vocabulary to compose correct, complete, and sufficient expressions of content and meaning of feedback.

Figure 22-68 contains an error message that occurred during a Save As file operation in an early version of Microsoft Word. This is a classic example that has generated considerable discussion among our students. The UX problems and design issues extend well beyond just the content of the error message.

In this Save As operation the user was attempting to save a file of unformatted data, calling it “data w/o format” for short. The resulting error message is confusing because it is about a folder not being accessible because of things like unavailable volumes or password protection. This seems about as unclear and unrelated to the task as it could be.

In fact, the only way to understand this message is to understand something more fundamental about the Save As dialogue box. The design of the File Name: text field is overloaded. The usual input entered here is a file name, which is by default associated with the folder name in the Save in: field at the top.

But some designer must have said “That is fine for all the GUI wusses, but what about our legions of former DOS users, our heroic power users who want to enter the full command-style directory path name for the file?” So the design was overloaded to accept full path names of files as well, but no clue was added to the labeling to reveal this option. Because path names contain the slash (/) as a dedicated delimiter, a slash within a file name cannot be parsed unambiguously so it is not allowed.

In our class discussions of this example, it usually takes students a long time to realize that the design solution is to unload the overloading by the simple addition of a third text field at the bottom for Full file directory path name:. Slashes in file names still cannot be allowed because any file name can also appear in a path name, but at least now, when a slash does appear in a file name in the File Name: field, a simple message, “Slash is not allowed in file names,” can be used to give a clear indication of the real error.

The most recent version of Word, as of this writing, half-way solves the problem by adding to the original error message: “or the file name contains a or /”.

Precise wording

Support user understanding of feedback content by precise expression of meaning through precise word choices. Do not allow wording of feedback to be treated as an unimportant part of interaction design.

Completeness of feedback

Support user understanding of feedback by providing complete information through sufficient expression of meaning, to disambiguate, make more precise, and clarify. For each feedback message, the designer should ask “Is there enough information?” “Are there enough words used to distinguish cases?”

The expression of a cognitive affordance should be complete enough to allow users to fully understand the outcomes of their actions and the status of their course of interaction.

Having to ponder over the meaning of feedback can lead to lost productivity. Help your users move on to the next step quickly, even if it is error recovery.

Short feedback is not necessarily the most effective. If necessary, add additional information to make sure that your feedback information is complete and sufficient.

In Figure 22-69 is an exit message from the Microsoft Outlook email system that we used previously (Figure 22-44) as an example about completeness of cognitive affordances and giving enough information for users to make confident decisions. This message is displayed when a user tries to exit the Outlook email system before all queued messages are sent. We also use it as an example here in the assessment section, even though technically the part of the system response that is at issue here is the lack of a cognitive affordance as feed-forward.

When users first encountered this message, they were often unsure about how to respond because it did not inform them of the consequences of either choice. What are the consequences of “exiting anyway?” One would hope that the system could go ahead and send the messages, regardless, but why then did it give this message? So maybe the user will lose those messages. What made it worse was the fact that control would be snatched away in 8 seconds, and counting. How imperious!

Most users we tested with took the right one, it seems, by making what they thought to be the conservative choice, not exiting yet. Figure 22-70 is an updated version of this same message, only this time it gives a bit more information about the repercussions of exiting prematurely, but it still does not say if exiting will cause messages to be lost or just queued for later.

Tone of feedback expression

When writing the content of a feedback message, it can be tempting to castigate the user for making a “stupid” mistake. As a professional interaction designer you must separate yourself from those feelings and put yourselves in the shoes of the user. You cannot know the conditions under which your error messages are received, but the occurrence of errors could well mean that the user is already in a stressful situation so do not be guilty of adding to the user’s distress with a caustic, sarcastic, or scornful tone.

The almost certainly apocryphal message in Figure 22-71 is an extreme example of an unhelpful message.

Usage centeredness of feedback

We mentioned that user centeredness is a design concept that often seems unclear to students and some practitioners. Because it is mainly about using the vocabulary and concepts of the user’s work context rather than the technical vocabulary and context of the system, we should probably call it “work-context-centered” design. This section is about how usage centeredness applies to feedback in the assessment part of the Interaction Cycle.

In Figure 22-72 we see a real email system feedback message received by one of us many years ago, clearly system centered, if anything, and not user or work context centered. Systems people will argue correctly that the technical information in this message is valuable to them in tracing the source of the problem.

That is not the issue here; rather it is a question of the message audience. This message is sent to users, not the systems people, and it is clearly an unacceptable message to users. Designers must seek ways to get the right message to the right audience. One solution is to give a non-technical explanation here and add a button that says “Click here for a technical description of the problem for your systems representative.” Then put this jargon in the next message box.

This message in the next example is similar in some ways, but is more interesting in other ways.

As an in-class exercise, we used to display the computer message in Figure 22-73 and ask the students to comment on it.

Some students, usually ones who were not engineering majors, would react negatively from the start. After a lot of the usual comments pro and con, we would ask the class whether they thought it was usage centered. This usually caused some confusion and much disagreement. Then we ask a very specific question: Do you think this message is really about an error? In truth, the correct answer to this depends on your viewpoint, a reply we never got from a student.

The system-centered answer is yes; technically an “error condition” arose in the operating system error-handling component when it got an interrupt from the printer, flagging a situation in which there is a need for action to fix a problem. The process used inside the operating system is carried out by what the software systems people call an error-handling routine. This answer is correct but not absolute.

From a user-, usage-, or work-context-centered view, it is definitely and 100% not an error. If you use the printer enough, it will run out of paper and you will have to replace the supply. So running out of paper is part of the normal workflow, a natural occurrence that signals a point where the human has a responsibility within the overall collaborative human-system task flow. From this perspective, we told our students we had to conclude that this was not an acceptable message to send to a user; it was not usage centered.

We decided that this exercise was a definitive litmus test for determining whether students could think user centrically. Some of our undergraduate CS students never got it. They stubbornly stuck to their judgment that there was an error and that it was perfectly appropriate to send this message to a user to get attention to attending the error.

Each semester we told them that it was okay that they did not “get it”; that they could still live productive lives, just not in any UX development role. Not everyone is cut out to take on a UX role in a project.

Just to finish up the analysis of this message:

Consistency of feedback

In the context of feedback, the requirement for consistency is essentially the same as it was for the expression of cognitive affordances: choose one term for each concept and use it throughout the application.

This guideline is a special case of consistency that applies to a situation where a button or menu selection leads the user to a new screen or dialogue box, a common occurrence in interaction flow. This guideline requires that the name of the destination given in the departure button label or menu choice be the same as its name when you arrive at the new screen or dialogue box. The next example is typical of a common violation of this guideline.

In Figure 22-74 we see an overlay of two partial windows within a personal document system. In the bottom layer is a menu listing some possible operations within this document system. When you click on Add New Entry, you go to the window in the top layer, but the title of that window is not Add New Entry, it is Document Data Entry. To a user, this could mean the same thing, but the words used at the point of departure were Add New Entry.

Finding different words, Document Data Entry, at the destination can be confusing and can raise doubts about the success of the user action. The explanation given us by the designer was that the destination window in the top layer is a destination shared by both the Add New Entry menu choice and the Modify/View Existing Entries menu choice. Because state variables are passed in the transition, the corresponding functionality is applied correctly, but the same window was used to do the processing.

Therefore, the designer had picked a name that sort of represented both menu choices. Our opinion was that the destination window name ended up representing neither choice well and it takes only a little more effort to use two separate windows.

In this example, consider the Simple Search tab, displayed at the top of most screens in this digital library application and shown in Figure 22-75.

That tab leads to a screen that is labeled Search all bibliographic fields, as shown in Figure 22-76.

We had to conclude that the departure label on the Simple Search tab and the destination label, Search all bibliographic fields, do not match well enough because we observed users showing surprise upon arrival and not being sure about whether they had arrived at the right place. We suggested a slight change in the wording of the destination label for the Simple Search function to include the same name, Simple Search, used in the tab and not sacrifice the additional information in the destination label, Search all bibliographic fields, as shown in Figure 22-77.

User control over feedback detail

When a significant volume of feedback detail is available, it is best not to overwhelm the user by giving all the information at once. Rather, give the most important information, establishing the nature of the situation, upfront and provide controls affording the user a way to ask for more details, as needed.

Information organization for presentation

There are entire books available on the topics of information visualization and information display design, among which the work of Tufte (1983, 1990, 1997) is perhaps the most well known. We do not attempt to duplicate that material here, but rather reference the interested reader to pursue these topics in detail from those sources. We can, however, offer a few simple guidelines to help with the routine presentation of information in your displays of results.

This guideline is the reason that newspapers are printed in columns.

Ben Shneiderman has a “mantra” for controlling complexity in information display design (Shneiderman & Plaisant, 2005, p. 583):

Train passengers in Europe will notice entering passengers competing for seats that face the direction of travel. At first, it might seem that this is simply about what people were used to in cars and busses. But some people we interviewed had stronger feelings about it, saying they really were uncomfortable traveling backward and could not enjoy the scenery nearly as much that way.

Believing people in both seats see the same things out the window, we wondered if it really mattered, so we did a little psychological experiment and compared our own user experiences from both sides. We began to think about the view in the train window as an information display.

In terms of bandwidth, though, it did not seem to matter; the total amount of viewable information was the same. All passengers see the same things and they see each thing for the same amount of time. Then we recalled Ben Shneiderman’s rules for controlling complexity in information display design (see earlier discussion).

Applying this guideline to the view from a train window, we realized that a passenger traveling forward is moving toward what is in the view. This traveler sees the overview in the distance first, selects aspects of interest, and, as the trains goes by, zooms in on those aspects for details.

In contrast, a passenger traveling backward sees the close-up details first, which then zoom out and fade into an overview in the distance. But this close-up view is not very useful because it arrives too soon without a point of focus. By the time the passenger identifies something of interest, the chance to zoom in on it has passed; it is already getting further away. The result can be an unsatisfying user experience.

Visual bandwidth for information display

One of the factors that limit the ability of users to perceive and process displayed information is visual bandwidth of the display medium. If we are talking about the usual computer display, we must use a display monitor with a very small space for all our information presentation. This is tiny in comparison to, say, a newspaper.

When folded open, a newspaper has many times the area, and many times the capacity to display information, of the average computer screen. And a reader/user can scan or browse a newspaper much more rapidly. Reading devices such as Amazon’s Kindle™ and Apple’s iPad™ are pretty good for reading and thumbing through whole book pages, but lack the visual bandwidth afforded for “fanning” through pages for perusal or scanning provided by a real paper book.

Designs that speed up scrolling and paging do help but it is difficult to beat the browsing bandwidth of paper. A reader can put a finger in one page of a newspaper, scan the major stories on another page, and flash back effortlessly to the “book-marked” page for detailed reading.

In our UX classes we used to have an in-class demonstration to illustrate this concept. We started with sheets of paper covered with printed text. Then we gave students a set of cardboard pieces the same size as the paper but each with a smaller cutout through which they must read the text.

One had a narrow vertical cutout that the reader must scan, or scroll, horizontally across the page. Another had a low horizontal cutout that the reader must scan vertically up and down the page. A third one had a small square in the middle that limited visual bandwidth in both vertical and horizontal directions and required the user to scroll in both directions.

You can achieve the same effect on a computer screen by resizing the window and adjusting the width and height accordingly. For example, in Figure 22-78, you can see limited horizontal visual bandwidth, requiring excessive horizontal scrolling to read. In Figure 22-79, you can see limited vertical visual bandwidth, requiring excessive vertical scrolling to read. And in Figure 22-80, you can see limited horizontal and vertical visual bandwidth, requiring excessive scrolling in both directions. It was easy for students to conclude that any visual bandwidth limitation, plus the necessary scrolling, was a palpable barrier to the task of reading information displays.

Structural consistency

We think Reisner (1977) helped clarify the concept of consistency, in the context of database query languages, when she coined the term “structural consistency.” In referring to the use of query languages, structural consistency simply required similar syntax (wording or user actions) to denote similar or related semantics. So, in our context, the expression of cognitive affordances for two similar functions should also be similar.

However, in some situations, consistency can work against distinguishability. For example, if a design contains two different kinds of delete functions, one of which is used routinely to delete objects within an application, but the other is dangerous because it applies to files and folders at a higher level, the need to distinguish these delete functions for safety may override this guideline for making them similar.

A simple example is seen in the common Next and Previous buttons that might appear, for example, for navigation among pictures in an online photo gallery. Although these two buttons are opposite in meaning, they both are a similar kind of thing; they are symmetric and structurally similar navigation controls. Therefore, they should be labeled in a similar way. For example, Go forward and Previous picture are not as symmetric and not as similar from a linguistic perspective.

Consistency is not absolute

Many design situations have more than one consistency issue and sometimes they trade-off against each other. We have a good example to illustrate.

Consider the case of multi-blade screwdrivers that are handy for dealing with different sizes and types of screws. In particular, they each have both flat-blade and Phillips-blade driver bits and each of these types comes in both small and large sizes.

Figure 22-81 illustrates two of these so-called “4-in-1” screwdrivers. As part of a discussion of consistency, we bring screwdrivers like these to class for an in-class exercise with students. We begin by showing the class the screwdrivers and explain how the bits are interchangeable to get the needed combination of blade type and size.

Next we pick a volunteer to hold and study one of these tools and then speak to the class about consistency issues in its design. They pull it apart, as shown in Figure 22-82.

The conclusion always is that it is a consistent design. We have another volunteer study the other screwdriver, always reaching the same conclusion. Then we show the class that there are differences between the two designs, which become apparent when you compare the bits at the ends of each tool, as shown in Figure 22-83.

One tool is consistent by blade type, having both flat blades, large and small, on one insertable piece and both Phillips blades on the other piece. The other tool is consistent by size, having both large blades on one insertable piece and both small blades on the other piece.

We now ask them if they still think each design is consistent and they do. They are each consistent; they each have intra-product consistency. Neither is more consistent than the other, but each is consistent in a different way and are not consistent with each other.

Consistency in design is supposed to aid predictability but, because there is more than one way to be consistent in this example, you still lack inter-product consistency and you do not necessarily get predictability. Such is one difficulty of interpreting and applying this seemingly simple design guideline.

Consistency can work against innovation

Final caveat: While a style guide works in favor of consistency and reuse, remember that is also can be a barrier to inventiveness and innovation (Kantrovich, 2004). Being the same all the time is not necessarily cool! When the need arises to break with consistency for the sake of innovation, throw off the constraints and barriers and dive through the wormhole to the creative side.

Avoiding anthropomorphism

Shneiderman and Plaisant (2005, pp. 80, 484) say that a model of computers that leads one to believe they can think, know, or understand in ways that humans do is erroneous and dishonest. When the deception is revealed, it undermines trust.

“Sorry, but I cannot find the file you need” is less honest and no more informative than something such as “File not found” or “File does not exist.” If attribution must be given to what it is that cannot find your file, you can reduce anthropomorphism by using the third person, referring to the software, as in “Windows is unable to find the application that created this file.” This guideline urges us to especially eschew chatty and over-friendly use of first-person cuteness, as we see in the next example.

Figure 22-84 contains a message from a database system after a search request had been submitted. Ignoring other obvious UX problems with this dialogue box and message, most users find this kind of use of first person as dishonest, demeaning, and unnecessary.

Just when you think all hope is lost, then along comes Clippy or Bob, your personal office assistant or helpful agent. How intrusive and ingratiating! Most users dislike this kind of pandering and insinuating into your affairs, offering blandishments of hope when real help is preferred.

People expect other humans to be able to solve problems better than a machine. If your interaction dialogue portrays the machine as a human, users will expect more. When you cannot deliver, however, it is overpromising. The example that follows is ridiculous and cute but it also makes our point.

Clearly the pop-up “help” in Figure 22-85 is not a real example, but this kind of pop-up in general can be intrusive. In real usage situations, most users expect better.

The case in favor of anthropomorphism

On the affirmative side, Murano (2006) shows that, in some contexts, anthropomorphic feedback can be more effective than the equivalent non-anthropomorphic feedback. He also makes the case for why users sometimes prefer anthropomorphic feedback, based on subconscious social behavior of humans toward computers.

In his first study, Murano (2006) explored user reactions to language-learning software with speech input and output using speech recognition. Users were given anthropomorphic feedback in the form of dynamically loaded and software-activated video clips of a real language tutor giving feedback.

In this kind of software usage situation, where the objectives and interaction are very similar to what would be expected from a human language tutor, “the statistical results suggested the anthropomorphic feedback to be more effective. Users were able to self-correct their pronunciation errors more effectively with the anthropomorphic feedback. Furthermore it was clear that users preferred the anthropomorphic feedback.” The positive results are not surprising because this kind of application naturally uses human–computer interaction that is very close to natural human-to-human interaction.

In a second study, Murano (2006) looked at Unix for a rank beginner, again employing speech input and output with speech recognition and again employing anthropomorphic video clips of real humans as feedback. He found anthropomorphic feedback to be more effective and more desired by users than other feedback.

However, we cannot see natural language interaction with Unix as a viable long-term alternative. Unix is complex and difficult to learn, not intended for beginners. Anyone intending to use Unix for more than just an experiment will perforce not remain a beginner for long. Any expert Unix user we have ever seen would surely find speech interaction less convenient and less precise than the lightning-fast typed commands usually associated with UNIX usage. If the interaction in this study was not anthropomorphic per se, speech input and output can convey the feeling of being the “equivalent” of anthropomorphic.

In his third study, Murano (2006) determined that, for direction-finding tasks, a map plus some guiding text was more effective than anthropomorphic feedback using video clips of a human giving directions verbally, with user preferences about evenly divided. The bottom line for Murano is that some application domains are more suited for anthropomorphic interaction than others.

Well-known studies by Reeves and Nass (1996) attempted to answer the question why anthropomorphic interaction might be better for some users in some kinds of applications. They concluded that people naturally tend to interact with a computer the same social way we interact with people, especially in cases where feedback is given as natural language speech (Nass, Steuer, & Tauber, 1994). People treat computers in a social manner if the output of computers treats them in a social manner.

While a social manner of interaction did seem to be effective and desired by users of tasks that have a human-to-human counterpart, including tasks such as natural language learning and tutoring in a teacher–student kind of interaction, it is unlikely that a mutually social style and anthropomorphic interaction would have a place in the thousands of other kinds of tasks that make up a large portion of real computer usage—installing driver software, creating a text document, updating a data spreadsheet,

The bottom line for us is that users may think they would prefer anthropomorphic user-computer dialogue because it is somehow friendlier or maybe they would prefer to interact with another human rather than having to interact with a computer. But the fact remains: a computer is not human. So eventually expectations will not be met. Especially for the use of computers to get things done in business and work environments, we expect users to tire quickly of anthropomorphic feedback, particularly if it soon becomes boring by a lack of variety over time.