A task analysis breaks down a complex task into its components—that is, its knowledge that and its knowledge how. To do a task analysis, you observe and query an expert (who could be yourself).

• Why someone would learn the skill
• Prerequisite skills, knowledge, and attitudes
• Special materials or tools required
• Warnings of dangers, either overall and at specific junctures
• The critical main steps (no more than 5 -7) and their sequence
• All other sub steps necessary to complete the task and their sequence
• How critical any given sub step is
• Conditions that must be satisfied before going on to the next step
• Reasons for doing a step at a particular point
• Signs of success for each step (for confirmations)
• Signs of failure for each step
• Steps that require graphics or other media besides text

1. Remind yourself of the objective and the degree of mastery required
2. Observe experts and take notes as they do the task.
3. Take notes as you observe an expert achieve the objective.
4. Slow down experts so that you can identify each step.
5. Ask the experts to speak aloud and say
   • what they are doing
   • why they are doing it
   • what warning they would issue (or remind themselves of)
   • how do they know if a step has succeeded
   • how do they know if a step has failed
6. List what you learned that you did not expect to

Experts may not be available for a variety of reasons. When you have to supply your own expertise, you first (and obviously) need to know the task thoroughly, consciously observe yourself doing it, and articulate aloud what your doing as you go.

In addition (or to supplement an expert's knowledge), look at the following:

1. The main interface (what happens when you click X or turn Screw B?)
2. The menus or choices available (what happens when you choose an item?)
3. Any documentation that comes with application or device.

The notes you take while you observe an expert are likely to be unorganized. In order for them to be useful, you have to redo them, preferably as sequenced lists and/or graphs. Both methods are elegant and parsimonious way to capture an experts' knowledge, skills, and work flow.

The most common way of representing expertise is a numbered list. That works best when you're taking quick notes, when the task consists of only a few steps, or when you yourself are the expert. But a long numbered list (more than seven items) sometimes obscures the forest, that is, the necessary big picture. For complex or unfamiliar tasks, it's preferable to have a representation that lets you see not only the steps but how they fit together.

Two of the most common ways to do that are linear and flowchart graphs. Which one you chose depends on the task you wish to represent. Linear graphs are best for straightforward processes; flowcharts are best when you have to show decisions and/or contingencies. The next two sections explain these ideas in more detail.

A linear graph shows a procedure's main tasks from left to right and its subtasks under the respective main task. The basic representational tools for a linear chart are boxes, lines, and arrows.

Here's the most general example:

Suppose, for example, we wanted to represent an expert's knowledge for "Creating a slide show with Dreamweaver's Timeline." The four main tasks would be as follows:

1. Preparing images
2. Placing the first image on the timeline
3. Adding key frames to the timeline
4. Invoking behaviors to send user to particular frames

The third main task has three necessary subtasks:

1. Deciding the keyframe's position
2. Highlighting the desired frame in the timeline
3. Selecting Modify>Timeline>Add Key Frame.

All three are shown below Main Task 3:

Whether this shows enough detail depends on what you're trying to teach, to whom, and when. For your first draft, for example, this may be all you need. Nor will experienced users need too much more.

However, you may wish to include contingencies, as with the next method.

When you want to capture more complex details a flowchart shows the main flow of tasks, especially the paths that depend on the user deciding whether some condition exists. The basic representational tools for a flow chart are boxes, decision diamonds, lines, and arrows.

For example, here is a flow chart for the same main task of adding keyframes to the timeline:

In this case, experts check that the Timeline inspector is visible:

• If it is, they highlight a frame.
• If it isn't, they display it and continue to the step where they highlight a frame.

The flowchart's value in this example is that it captures a possible problem for novices ("Is the timeline inspector visible?"). That's something about which an expert might not need reminding. Given your audience, however, that may be exactly what you need.

There is no reason, however, not to combine both forms of representation, depending on what you need at any given point of your design. Here's an example:

• In case you later discover a step that needs clarifying or one that you've misunderstood completely.
• To review your work for accuracy