In the discussion of letter-writing, we saw that very similar end objectives could be achieved in very different ways using different tools (pen or word processor plus printer). The two scenarios described similar domain tasks – what the user is achieving in the world – but involved different device tasks – what the user had to do using the available tools to achieve that effect. One of the most important challenges of design is often to ensure that there is a good ‘fit’ between the domain tasks and the device tasks. In an ideal world, the device would be almost invisible to the user – not in the sense that it cannot be seen, but in the sense that it is not noticed.

We can draw on an analogy of a hammer: if you are hammering in a nail, things always go best when you are unaware of the hammer itself; it is just an extension of your hand and the hammering action is fluid and easy. Then you bang your finger, and suddenly that flow of activity is broken; you are intensely aware of the hammer as a separate object, and you have to work hard to restore the earlier productive hammering action. Tools should be ready-to-hand in the way that a hammer is to a carpenter: the user should not be fighting with the tool, but using the tool easily and naturally to achieve their tasks, almost unaware of its existence. For Linden, the worst things that might happen are her pen leaking or running out of ink. Remi’s work is more prone to the tools getting in the way of the task, although, conversely, his tools may also provide him with more active support for those same tasks.

Of course, there are cases where the computer system is the focus of the activity: a good computer game is engrossing, but it does depend on the computer system being there and visible: it is the focus of attention. However, even in this case, the user should be able to focus on the game rather than being distracted by pictures going jittery, the sound fading unpredictably or other unintended features.

Of course, games are not the usual focus of task analysis, which is more commonly concerned with the productive kinds of tasks that are found in work environments (offices, factories, etc.). In the remainder of this unit, we will focus our attention on the kinds of work tasks that have a clear goal – typically an end product.

Task analysis of any kind starts from data – information about the work and the work setting. For HTA the data that is needed is data about procedures – about how activities are structured into tasks. For ER and KB analysis, the data that is needed concerns objects in the work domain and their interrelationships, and maybe also the actors (people that are essential to getting the work done).

In the scenarios above, we talked about going into Linden’s and Remi’s offices and observing them. Implicitly, while observing them we were also taking notes about their activities that could be used later for analysis. Observation and note-taking (or even video-recording) are one way of gathering the data that is needed for task analysis. Another way of getting such information is by interviewing users (i.e. the people who perform the tasks being studied). Again, responses can be noted by hand, or recorded using a tape-recorder. Each of these techniques has advantages and disadvantages.

Interviewing is often more efficient than observation. As people talk about their work, they use a particular vocabulary that expresses their understanding of what they do and how they work that can usefully be adopted in any computer support for their tasks. You find out how they think they perform their jobs and the things that they perceive as being important.

Unfortunately, people are often unable to articulate what they really do. This may be because they are so immersed in their working environments, so familiar with the way things work, that they take much of their knowledge for granted. Often the most important things about the way they work are the ones that are most obvious to them, and therefore the ones they will forget to mention. Also, as they become experts at their tasks, they forget all the details: they develop ‘compiled skills’ which becomes difficult for them to break down and describe fully. To take a simple example that may be familiar to you: if you are driving a manual car, as you pull away from a junction you will change up the gears. When do you change gear (e.g. from third to fourth)? What is the detailed procedure you follow as you change? Do you take your eyes off the road for any reason? Learner drivers are very aware of the procedure; each foot movement, each glance in the mirror, the act of feeling for the gear lever (maybe looking for it) are all deliberate actions. As expertise develops, the conscious awareness of the process diminishes. To understand users’ tasks in detail, it is often necessary to observe them, to identify taken for granted knowledge and compiled skills.

A third source of data for task analysis is often existing documentation: there may be procedure documents that describe how tasks should be performed (which may or may not describe how they are actually performed). In what follows, we are assuming that data has be acquired from somewhere, and we focus on ways of analysing that data.

Before we start, though, a note of caution about the limits of task analysis: it’s no good for revolutionary design. Every now and then, a totally new kind of design appears on the scene – one that really changes the way we do our work, or think about interaction. Two of the examples from recent years that you will be familiar with are the Graphical User Interface (GUI), which moved us forward from the text-based command-line interfaces of an earlier generation and made computing much more accessible to non-specialists, and the World Wide Web, which has revolutionised information access and hastened the globalisation of interactions and commercial transactions. For every high-impact success like these, there are untold numbers of failures – revolutionary ideas that simply failed to catch on and faded into oblivion.

Contrast these with the word processor, which evolved from the typewriter and retained many features of its predecessor: each generation of word processor has moved a little further from its origins, as users find new uses for the current generation of machine and adapt their behaviour to the new possibilities, which are then ‘designed in’ to the next generation products, so that we get co-adaptive behaviour (with users adapting to new systems, which are then re-designed to support new uses, which…)

Task analysis provides good support for design evolution, where understanding of the current task – the task structure, the entities and actors – is used as a starting point for new design. It is no use for design revolution, which typically involves creating new possibilities, that simply did not exist before, and introducing new concepts (e.g. the graphical object or the hypertext link).