Task-Centered User Interface Design
A Practical Introduction
by Clayton Lewis and John Rieman
Copyright ©1993, 1994: Please see the "shareware notice" at the front of the book.
Contents | Foreword | ProcessUsers&Tasks | Design | Inspections | User-testing |Tools | Documentation |

4.1 Cognitive Walkthroughs
        4.1.1 Who should do a walkthrough, and when?
        4.1.2 What's needed before you can do a walkthrough?
        4.1.3 What should you look for during the walkthrough?
        4.1.4 What do you do with the results of the walkthrough?
4.2 Action Analysis
        4.2.1 Formal Action Analysis
        4.2.2 Back-of-the-Envelope Action Analysis
4.3 Heuristic Analysis
4.4 Chapter Summary and Discussion


4.1.4 What do you do with the results of the walkthrough?


Fix the interface! Many of the fixes will be obvious: make the controls more obvious, use labels that users will recognize (not always as easy as it sounds), provide better feedback. Probably the hardest problem to correct is one where the user doesn't have any reason to think that an action needs to be performed. A really nice solution to this problem is to eliminate the action -- let the system take care of it. If that can't be done, then it may be possible to re-order the task so users will start doing something they know needs doing, and then get prompted for the action in question. The change to the "spelling dictionary" interaction that we described is one example. For the portable computer speed problem, the system might monitor processor load and ask if the user wanted to change to low speed whenever the average load was low over a 20 minute period, with a similar prompt for high speed.

Example: Cognitive Walkthrough of Setting Mac Background Printing

The task is to turn on background printing. The interface and action sequence are described in the box at the beginning of the chapter. We'll consider users who have some experience with this computer, but who have never set the background printing option.


The walkthrough analysis proceeds action by action.


The first action is to pull down the apple menu. (We might also aggregate the first two actions, saying "select Chooser from the apple menu." The analysis should reveal pretty much the same things.) We predict that users want to find a menu item that lets them select background printing -- that is, they want to do the right thing. The Apple menu is clearly visible, although it might not be clear that it's a menu to a first-time user. And since our users have used the Mac before, it's reasonable that they might look for a "system" function here. However they might also think background printing is a "print" option, and go looking under the "Print..." menu item under "File." This seems like it could be a problem. The low-level feedback is OK -- a menu drops. But it would be better if the menu had some items in it that clearly had to do with printing.


The second action is to select "Chooser" from the menu. The user is still trying to find the "printer" options. Will they realize that "Chooser" is the right menu item? It seems like they could just as reasonably select "Control Panel." Once again, we have to fault the labeling. Once the action is performed, however, the printer icons in the dialog box at least suggest that this is the right tactic. But notice: still nothing visible about "background printing."


Third action is click on the current printer type, which is laser printer. Why would the user want to do this? We can't come up with any good rationalization. Some users may not even see that the action is available, since icons in a scrolling window aren't a common Mac interface technique. But the feedback, assuming the user does click the icon, is finally a success: here's the background printing toggle we were looking for (assuming the user sees it below the list of printer names).


Fourth action is to click "On" for background printing. This seems to be problem free. It's exactly what the user wants to do;, the control is clearly visible; and the feedback -- the button becomes filled in -- is informative.


Final action is to close the Chooser window by clicking the close box in the upper left corner. We've been calling it a "dialog box," but it's actually a window filled with controls. This seems odd. Users with Mac experience will probably think that they need to click the "OK" button, but there isn't one. And the close box is in the diagonally opposite corner from where the "OK" button should be, so it may be especially hard to find. This also raises a feedback question. Users expect dialog boxes to put options into effect when "OK" is clicked. Since there's no "OK" button, users may wonder if just closing the window activated the options.


Summary


There's a real start-up problem with this task. The user wants to set "background printing" but he or she has to go through three levels of controls that don't seem very closely related to that goal: the apple menu, the "chooser" menu item, and the printer type. It seems like all of these things need to be revised to make the path more obvious. A better solution might be to put the background printing toggle into a place where the user might already be looking: make it part of the dialog box that comes up when "Print" is selected from a "File" menu. The other noticeable problem with the interface is the use of a window instead of a dialog box with an "OK" button.

Credits and Pointers: Cognitive Walkthrough


The cognitive walkthrough was developed by Clayton Lewis, Peter Polson, Cathleen Wharton, and John Rieman. A description of the theoretical foundations of the method can be found in:



The method has been tested in several situations. A summary and discussion of those tests, along with additional examples of interface success and failure stories, is given in:

Copyright © 1993,1994 Lewis & Rieman
Contents | Foreword | ProcessUsers&Tasks | Design | Inspections | User-testing |Tools | Documentation |