The back-of-the-envelope approach to action analysis foregoes detailed predictions in an effort to get a quick look at the big picture. We think this technique can be very valuable, and it's easy to do. Like the formal analysis, the back-of- the-envelope version has two phases: list the actions, then think about them. The difference is that you don't need to spend a lot of time developing a detailed hierarchical breakdown of the task. You just list a fairly "natural" series of actions and work with them.

A process that works well for listing the actions is to imagine you are explaining the process to a typical user. That means you aren't going to say, "take your hand off the keyboard and move it to the mouse," or "scan down the menu to the 'chooser' item." You'll probably just say, "select 'chooser' from the apple menu." You should also put in brief descriptions of mental actions, such as "remember your password," or "convert the time on your watch to 24-hour time."

Once you have the actions listed there are several questions you can ask about the interface:

You can get useful answers to all these questions without going into fraction-of-a-second details. At the action level you'd use in talking to a user, EVERY ACTION TAKES AT LEAST TWO OR THREE SECONDS. Selecting something from a menu with the mouse, entering a file name, deciding whether to save under a new name or the old one, remembering your directory name -- watch over a user's shoulder sometime, or videotape a few users doing random tasks, and you'll see that combined physical and mental time for any one of these actions is a couple of seconds on a good day, three or four or even ten before morning coffee. And you'll have to start measuring in minutes whenever there's any kind of an error or mistake.

By staying at this level of analysis, you're more likely to keep the task itself in mind, along with the user's work environment, instead of getting lost in a detailed comparison of techniques that essentially do the same thing. For example, you can easily use the back-of-the-envelope results to compare your system's proposed performance with the user's ability to do the same task with typewriters, calculators, and file cabinets.

This kind of action analysis is especially useful in deciding whether or not to add features to an interface, or even to a system. Interfaces have a tendency to accumulate features and controls like a magnet accumulates paperclips in a desk drawer. Something that starts out as a simple, task-oriented action sequence can very quickly become a veritable symphony of menus, dialog boxes, and keystrokes to navigate through the options that various people thought the system should offer. Often these options are intended as "time savers," but the user ends up spending an inordinate amount of time just deciding which time saver to use and which to ignore. (One message you should take away from the table of action times is that it takes real time to decide between two ways of doing something.)

A few quick calculations can give you ammunition for convincing other members of a development team which features should or should not be added. Of course, marketing arguments to the contrary may prevail: it often seems that features sell a program, whether or not they're productive. But it's also true that popular programs sometimes become so complicated that newer, simpler programs move in and take over the low end of the market. The newcomers may even eventually displace the high-functionality leaders. (An example of this on a grand scale is the effect of personal computers on the mainframe market.)

Example: Back-of-the-envelope action analysis

Here's an example of an interface where a quick, informal action analysis shows real problems, which were gradually alleviated as the interface evolved. (We'll spare you from reading a second action analysis of the Mac chooser.) The interface is the controls to a 35-mm camera. When these cameras first became popular in the 1950s, the action sequence needed to take a picture went something like this:

   - take light meter out of pocket

   - make sure film speed is set correctly on light meter

	-- remember: what speed of film is in the camera

   - aim light meter at scene

   - read light value from needle on light meter

   - adjust calculator dial on light meter to light value

   - the calculator shows several possible combinations of

     f-stop and shutter speed, all of which give the

     correct exposure.  So...

      -- remember: big f-stop number means small lens opening

      -- remember: small lens opening means more depth of field

      -- remember: big shutter speed number means short exposure

      -- remember: short exposure means moving things aren't blurred

      -- decide: which combination of f-stop and speed to use

   - set the f-stop on the camera lens

   - set the shutter speed on the camera speed dial

   - remove the lens cap

   - cock the shutter

   - aim the camera

   - focus the camera

      -- remember: if lens aperture is small, depth of field is shallow

   - press the shutter release

   - advance the film

(Whew!)

Starting with the action list shown above, the camera designers could make rough estimates, or observe one or two users with a mock-up, and find that most actions in the list would take at least a couple of seconds. Some might take several seconds. These ballpark results would predict that it could take on the order of 30 seconds to take a photograph, and that's for a skilled user!

The analysis should make it clear that the interface would be hard to operate for several reasons:

    * It takes too long to take a picture.

    * There are too many actions to be learned.

    * Some of the actions have to be "understood" -- for example, what IS depth of field? This makes the interface harder to learn and slower to use.

    * Every action is an opportunity for error, and almost any error can ruin the final result.

The analysis would also show that more than half the time was spent metering the light and setting the exposure, a very system-oriented activity that many camera users don't want to think about.

We don't know if there was ever a back-of-the-envelope action analysis done on 35-mm cameras, but the development of the camera interface can be broadly described as an ongoing effort to combine or eliminate the steps described above, with the exposure-setting functions being the first to go. The ultimate realization of this effort is the modern "point- and-shoot" pocket 35-mm. The camera reads the film speed off the film cassette, light-meters the scene, selects a combination of shutter speed and f-stop, and turns on a flash if needed. (We didn't even mention the half-dozen or more additional actions needed to do flash photography before electronics!) Focusing with the point-and-shoot camera is automatic, and a motor cocks the shutter and winds the film. All that's left for the user is to aim and press the shutter release.

However, another look at the example illustrates some of the shortcomings of any action analysis, formal or informal. The modern, fully automated 35-mm camera isn't the only kind of camera people buy today. Many people buy cameras that are not fully automated or that let the user override the automation. Some of those purchasers are experienced photographers who believe they can get better or more varied results manually. Some are people who just like to have a lot of controls on their cameras. Whatever the reason, these contextual and market factors won't show up in an action analysis. But they can be discovered by designers who spend time getting to know the users.

The quantitative, engineering-style analysis of actions was initially developed by Stuart Card, Thomas Moran, and Alan Newell, based on theories of cognitive psychology that Newell produced with Herbert Simon. The Card, Moran, and Newell approach is referred to as GOMS modelling (for Goals, Operators, Methods, and Selection). It's described in detail in:

Important extensions to the work, including verifications and additions to the list of action times, have been made by a number of researchers. An excellent overview of this work is given in:

The detailed action analysis on telephone operator workstations is described in:

The back-of-the-envelope analysis we describe draws on observations by David Kieras on the procedures for doing formal action analysis and interpreting its results. Kieras has worked to make the GOMS method easier to learn and more reliable. If you need to learn more about formal action analysis, a good place to start would be: