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.2 Action Analysis


Action analysis is an evaluation procedure that forces you to take a close look at the sequence of actions a user has to perform to complete a task with an interface. In this book we'll distinguish between two flavors of action analysis. The first, "formal" action analysis, is often called "keystroke-level analysis" in HCI work. The formal approach is characterized by the extreme detail of the evaluation. The detail is so fine that, in many cases, the analysis can predict the time to complete tasks within a 20 percent margin of error, even before the interface is prototyped. It may also predict how long it will take a user to learn the interface. Unfortunately, formal action analysis isn't easy to do.


The second flavor of action analysis is what we call the "back of the envelope" approach. This kind of evaluation won't provide detailed predictions of task time and interface learnability, but it can reveal large-scale problems that might otherwise get lost in the forest of details that a designer is faced with. As its name implies, the back-of- the-envelope approach doesn't take a lot of effort.


Action analysis, whether formal or back-of-the-envelope, has two fundamental phases. The first phase is to decide what physical and mental steps a user will perform to complete one or more tasks with the interface. The second phase is to analyze those steps, looking for problems. Problems that the analysis might reveal are that it takes too many steps to perform a simple task, or it takes too long to perform the task, or there is too much to learn about the interface. The analysis might also reveal "holes" in the interface description -- things that the system should be able to do but can't. And it could be useful in writing or checking documentation, which should describe the facts and procedures that the analysis has shown the user needs to know.




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