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

Prev 4.1.1 Who should do a walkthrough, and when? Next 4.1.3 What should you look for during the walkthrough?


4.1.2 What's needed before you can do a walkthrough?




You need information about four things. (1) You need a description or a prototype of the interface. It doesn't have to be complete, but it should be fairly detailed. Things like exactly what words are in a menu can make a big difference. (2) You need a task description. The task should usually be one of the representative tasks you're using for task-centered design, or some piece of that task. (3) You need a complete, written list of the actions needed to complete the task with the interface. (4) You need an idea of who the users will be and what kind of experience they'll bring to the job. This is an understanding you should have developed through your task and user analysis.




HyperTopic: Common Mistakes in Doing a Walkthrough
In teaching people to use the walkthrough method, we've found that there are two common misunderstandings. We'll point those out here, so you'll be on guard to avoid them.




First, many evaluators merge point (3) above into the walkthrough evaluation process. That is, they don't know how to perform the task themselves, so they stumble through the interface trying to discover the correct sequence of actions -- and then they evaluate the stumbling process.




There may be times when that approach is useful, but it misses an important part of the walkthrough method. In the walkthrough, you should START WITH A CORRECT LIST OF THE INDIVIDUAL ACTIONS needed to complete the given task: Click button "File", Type in "Smith Letter", Click button "OK," etc. If you have to explore the interface to identify those actions, fine -- but that's not the walkthrough. The walkthrough begins when you have the list of actions in hand. The reason for this approach is that, in the best of all worlds, the user should identify and perform the optimal action sequence. So the walkthrough looks at exactly that sequence. If the walkthrough shows that the user may have trouble identifying or performing one of the actions, your primary interest is not what the user will do when that problem arises -- what you really want to know is the fact that there is a problem here, which needs to be corrected.




The second point that many first-time users of the walkthrough method miss is to that the walkthrough DOES NOT TEST REAL USERS ON THE SYSTEM. Of course, watching real users try out the interface can be a valuable approach, and we discuss it in detail in Chapter 5. But the walkthrough is an evaluation tool that helps you and your co-workers apply your design expertise to the evaluation of the interface. Because you can imagine the behavior of entire classes of users, the walkthrough will often identify many more problems than you would find with a single, unique user in a single test session.














Copyright © 1993,1994 Lewis & Rieman







Contents | Foreword | ProcessUsers&Tasks | Design | Inspections | User-testing |Tools | Documentation |