The formal approach to action analysis has been used to make accurate predictions of the time it takes a skilled user to complete tasks. To predict task times, the times to perform each small step of the task, physical or mental, are estimated, and those times are totalled. Most steps take only a fraction of a second. A typical step is a keystroke, which is why the formal approach is often called "keystroke- level analysis."

The predictions of times for each small step are found by testing hundreds of individual users, thousands of individual actions, and then calculating average values. These values have been determined for most of the common actions that users perform with computer interfaces. We summarize those values in the tables below. If an interface control isn't in the table, it might be possible to extrapolate a reasonable value from similar devices, or user testing might have to be done for the new control.

The procedure for developing the list of individual steps is very much like programming a computer. The basic task is divided into a few subtasks, like subroutines in a computer program. Then each of those subtasks is broken into smaller subtasks, and so on until the description reaches the level of the fraction-of-a-second operations listed in the table. The end result is a hierarchical description of a task and the action sequence needed to accomplish it.

PHYSICAL MOVEMENTS
Enter one keystroke on a standard keyboard:	.28 second	Ranges from .07 second for highly skilled typists doing transcription, to .2 second for an average 60-wpm typist, to over 1 second for a bad typist. Random sequences, formulas, and commands take longer than plain text.
Use mouse to point at object on screen	1.5 second	May be slightly lower -- but still at least 1 second -- for a small screen and a menu. Increases with larger screens, smaller objects.
Move hand to pointing device or function key /td>	.3 second	Ranges from .21 second for cursor keys to .36 second for a mouse.
VISUAL PERCEPTION
Respond to a brief light	.1 second	Varies with intensity, from .05 second for a bright light to .2 second for a dim one.
Recognize a 6-letter word	.34 second
Move eyes to new location on screen (saccade)	.23 second
MENTAL ACTIONS
Retrieve a simple item from long-term memory	1.2 second	A typical item might be a command abbreviation ("dir"). Time is roughly halved if the same item needs to be retrieved again immediately.
Learn a single "step" in a procedure	25 seconds	May be less under some circumstances, but most research shows 10 to 15 seconds as a minimum. None of these figures include the time needed to get started in a training situation.
Execute a mental "step"	.075 second	Ranges from .05 to .1 second, depending on what kind of mental step is being performed.
Choose among methods	1.2 second	Ranges from .06 to at least 1.8 seconds, depending on complexity of factors influencing the decision.

Example: Formal action analysis

Here's an example of a formal action analysis, roughly in the style described by David Kieras (see Credits and Pointers).

The top-level goal is to turn on background printing. Our top-level analysis of the task is:

      Method to accomplish goal of turning on background printing

          o Step 1. Accomplish goal of making printer dialog box visible.

          o Step 2. Accomplish goal of setting printer controls.

          o Step 3. Accomplish goal of putting away printer dialog box.

          o Step 4. Report goal accomplished

Here are some points to note about this first level. It doesn't include any actual, physical or mental actions. It is a "method" (the human version of a subroutine), and it's described in terms of goals that need to be accomplished. As we'll see, each of these goals will also be achieved with "methods." Also note that the three-step process is one example of a very common, generic Mac sequence: get a dialog box, set its controls, put it away. We could replace the word "printer" with "file" in Steps 1-3 and the procedure would work for saving a file. That says something good about the interface: it's consistent, so the user can learn one procedure and apply it to accomplish many things. Finally, note that there's an explicit step to report that the goal has been accomplished. This is parallel to the "return" call of a computer subroutine. In some procedures we might also make verifying the goal an explicit step.

Next we have to expand each step into methods. Step 1 expands into selecting from the menu. We'll skip the details of that and go on to expanding Step 2:

      Method to accomplish goal of setting printer controls.

          o Step 1. Accomplish goal of specifying printer type.

          o Step 2. Accomplish goal of setting background printing control.

          o Step 3. Report goal accomplished.

The methods we're describing are an explicit description of how we believe the user will conceptualize the task. Here we've had to make a decision, a judgement call, about what the user thinks. We've decided to break setting the printer controls into two steps, each with its own method. But another analyst might argue that the user will think of the task at this level as a single method or procedure, a single series of actions with the single goal of setting the background printing option in the dialog box. The results of the analysis could be somewhat different if that approach were taken.

We'll stay with the two-method approach and expand its first step. As it happens, there are two ways to specify the printer type. The user can click on the laser printer icon, as shown in the action sequence at the beginning of the chapter. Or, the user can type the first letter of the icon name, "Laser Printer." The formal analysis requires that we write a "selection rule," an if-then statement, that describes what conditions the user will consider to choose between the two techniques.

   Selection rule for goal of specifying printer type.

      IF hand is on mouse

      THEN accomplish goal of specifying printer with mouse.

      IF hands are on the keyboard

      THEN accomplish goal of specifying printer with keyboard

      Report goal accomplished

Now we'll expand the first of those options.

      Method for accomplishing goal of specifying printer with mouse.

          o Step 1. Recall current printer type.

          o Step 2. Match type to name/icon in list.

          o Step 3. Move to and click on icon.

          o Step 4. Verify that icon is selected.

          o Step 5. Report goal accomplished.

This is the lowest level of the hierarchy for this action. It describes low-level physical and mental actions at roughly the "keystroke" level. We can assign times to those actions as follows:

   Recall current printer type:                  1.2 second

      - This is just recalling an item from long-term memory

   Match type to name/icon list:                   1 second

      - This is a combination of moving the eyes, reading

        the name of the icon, and performing the mental step

        of matching.  It would take longer if there were

        more than two icons to choose from.

   Move to and click on icon:                    1.5 second

      - Standard mouse movement time.  We know from the

        selection rule that the hand is already on the mouse.

   System time to highlight icon:                 .1 second

      - We've just guessed at this.

   Verify that icon is selected:                  .2 second

      - This is a combination of recognizing the change in

        intensity and making the mental step of interpreting

it.

   Report goal accomplished.                      .1 second

      -  A simple mental step.

This totals to 4 seconds. The selection rule that preceded the actions would add at least 1 second more. If you have a Mac handy and actually time yourself, you'll probably do the task a little faster. That's largely because you've already decided on a method, recalled your printer type, and have it's icon in mind (which will speed the matching process). But the method predicts that, on the average for a skilled user, setting the printer type will take about 5 seconds.

Points Raised by the Analysis

To complete the formal analysis we'd have to go down to the keystroke level for each of the steps in the process. We'd find that the full task would take on the order of 10 to 15 seconds on a fast Mac with a hard drive, but it could take 30 seconds or more on one of the early Macs with only a floppy drive. Most of the system time goes into opening and closing the dialog box. Time-wise, any small amount that might be shaved off the 8 to 10 seconds of user activity would be overshadowed by the savings that could be achieved by providing faster hardware.

But the analysis can highlight some problems in areas other than task time. We noted that evaluators might differ on whether "setting printer type" should be a separate goal or merged into the goal of setting background printing. If the evaluators have trouble making that decision, it's a good bet that users will have a related difficulty. The analysis doesn't really suggest a solution here, only a potential problem.

Another question that the analysis highlights is the need for a selection rule to decide between keyboard and mouse selection of the printer type. Is the rule we've proposed a good one? If the user has just used the mouse to choose from the menu, will the keyboard option ever be appropriate? This requires some further thought, since dialog boxes with selectable lists are a common feature in the interface. The selection technique should be consistent, but it should also be quick. Do the occasions when the keyboard will be used justify a 1 second decision penalty every time a list appears?

The analysis might also call into question the large number of steps needed to do this fairly simple task. Of course, as you can probably see, any analysis at this level produces a "large" number of steps, so we can't be sure there's a problem here without comparing the task to some other tasks of similar complexity. A related issue is the task's long- term memory requirements. The analysis makes it clear that the user must recall the printer type. Will the user know the printer type?

Summary

The formal analysis takes a lot of work, and it's not clear that it was worth it in this case, at least not for the timing results. But looking closely at the actions did reveal a few problems that go deeper than timing, including the way the user should think about setting printer type, the question of multiple selection methods for lists, and the amount of knowledge required to do this apparently trivial task.

A full-blown formal analysis of a complex interface is a daunting task. The example and the size of the time values in the table should give some idea of why this is so. Imagine you want to analyze two designs for a spreadsheet to see which is faster on a given task. The task is to enter some formulas and values, and you expect it to take the skilled user on the order of 10 minutes. To apply the formal action analysis approach you'll have to break the task down into individual actions, most of which take less than a second. That comes out to around 1000 individual actions, just to analyze a single 10-minute task! (There will probably be clusters of actions that get repeated; but the effort is still nontrivial.)

A further problem with formal analysis is that different analysts may come up with different results, depending on how they see the task hierarchy and what actions they predict a user will take in a given situation. (Will the user scan left, then down the spreadsheet? Down then left? Diagonally? The difference might be seconds, swamping other details.) Questions like this may require user testing to settle.

Because it's so difficult, we think that formal action analysis is useful only in special circumstances -- basically, when its high cost can be justified by a very large payoff. One instance where this was the case was the evaluation of a proposed workstation for telephone operators (see the article by Gray et al listed in Credits and Pointers, below). The phone company contracting the action analysis calculated that a savings of a few seconds in a procedure performed by thousands of operators over hundreds of thousands of calls would more than repay the months of effort that went into the evaluation.

Another place formal action analysis can be effective is for segments of the interface that users will access repeatedly as part of many tasks. Some examples of this are choosing from menus, selecting or moving objects in a graphics package, and moving from cell to cell within a spreadsheet. In each of these examples, a savings of a few tenths of a second in an interaction might add up to several minutes during an hour's work. This could justify a detailed analysis of competing designs.

In most cases, however, a few tenths of a second saved in performing an action sequence, and even a few minutes saved in learning it, are trivial compared to the other aspects of the interface that we emphasize in this book. Does the interface (and the system) do what the user needs, fitting smoothly into the rest of the user's work? Can the user figure out how the interface works? Does the interface's combination of controls, prompts, warning messages, and other feedback allow the user to maintain a comfortable "flow" through a task? If the user makes an error, does the system allow graceful recovery? All of these factors are central, not only to productivity but also to the user's perception of the system's quality. A serious failure on any of these points isn't going to be countered by shaving a few seconds off the edges of the interface.