It is part of the orthodoxy of human-computer interaction that the activities of people at work can be described as ‘Tasks’. No modern textbook on the subject would be complete without a description of the topic of task analysis (see Hix and Hartson, 1993; Dix, et al., 1993 and Bass & Coutaz, 1991 as examples) and many approaches to doing tasks analysis exist in the literature (Diaper, 1989). In the real world of system development, however, a task analysis is almost never done and most systems analysts, designers and programmers are completely unaware of task analysis or why they should be doing it.

Partly this is because of a widespread lack of understanding of the need for high-quality human-computer interactions. Partly it is because most task analysis techniques are impractical, expensive and do not fit with mainstream software development techniques. Even the most robust and practical of existing approaches, (e.g. hierarchical task analysis—HTA; Annett and Duncan, 1967), suffer to some extent from these problems, as well as from a lack of integrated tool support.

Yet a part of the problem is also that many of the task analysis techniques that exist are based on inadequate notions of what tasks are. A view of tasks as being simply sequences or hierarchies of actions, or first-order grammars for behaviour (e.g. TAG, Payne and Green, 1986) is perhaps not sufficient and, while some approaches do include notions such as ‘Goal’ and ‘Context’ (e.g. GOMS, Card, Moran and Newell, 1983; and HTA, Annett and Duncan, 1967.) the wide variety of techniques and notations in the field as a whole, indicates a lack of clarity as to what a task is and how it should be described. As Walsh (1989) put it;

"In different methods, it is possible to find a description of tasks expressed in terms of one, some or all of the following: objects, actions, roles, goals, procedures, functions, processes, forms, attributes, relations, predicates, rules, inputs/outputs, and transitions between states." (Walsh, 1989, p191)

I do not propose, in this paper, to attempt to define yet another task analysis approach but, instead, to attempt to state as clearly as possible what a task is. The hope is that future task analysis approaches adopting this terminology will have a firmer foundation to build upon and that the use of a common vocabulary will enable researchers to communicate more easily about this topic.

In an earlier paper (Storrs, 1994) I argued that:

"... people ... act to achieve their purposes. This means that they are constantly engaged in goal-driven, sometimes planned behaviour. For some of this behaviour, the plan, or the goal structure is fixed to a greater or lesser degree and this kind of behaviour is what we normally call tasks. Some of this task-related behaviour will involve interactions and some of these interactions may involve computers." (Storrs, 1994, p186)

This seems like a good place to begin and, in the spirit of taking one step further, I propose the following definition of ‘Task’.

This definition asserts an important relationship between goals and actions which I put at the heart of the meaning of ‘Task’. A task thus becomes a purposive activity. The things that people do, when they do work, are not meaningless acts. They are done for a purpose and the purpose is to satisfy a goal.

The definition can be contrasted with that of Shepherd (1989) who separates ‘Goal’ and ‘Task’ such that a goal has an associated task for achieving it and a ‘Task’ is a set of

"... facilities and constraints on how the goal might be attained and an associated operation which refers to what is actually done in the set of circumstances constrained by the task." (Shepherd, 1989, p20)

Johnson et al. (1988) also distinguish tasks from the goals they serve. The task itself being only the activity required to bring about a state change in some domain.

The definition of ‘Task’ given above allows for the decomposition of tasks into sub-tasks (but please note that it does not insist on a hierarchical decomposition). It also leaves open the ordering of sets of tasks and actions, which I will return to later. As it is expressed, it suggests that all the ordered sets of tasks and actions that would satisfy a goal are part of the task’s definition. This, of course, is not normally possible in practice.

The concept of ‘Goal’ in the definition above is itself defined as follows.

The object of the intended state change may be anything at all (for instance, the agent’s own knowledge, a database, or some external, physical object). What I mean by an ‘autonomous agent’ is described more fully in an earlier paper (Storrs, 1989) but can be substituted for by ‘person’ without any problems. Note that Diaper (1989) also allows animals and machines to perform tasks. This is only permissible in my definition if the animals or machines concerned are capable of generating their own purposes (Storrs, 1989; Storrs, 1994) but for Diaper, who deliberately excludes goals from his definition of ‘Task’, any agent performing activity may be performing a task.

Finally, here is the definition for ‘Action’.

This definition is slightly problematic in that it leaves ‘Act’ undefined but it is as far as we need to go. It allows mental acts to be included as actions that will satisfy goals, so that ‘deciding’ or ‘perceiving’, for instance, can be the means of performing tasks.

There is another term, which has not appeared yet, but which is important to the definition of ‘Task’ and that is ‘Event’. Events occur in the world as the result of activity of all sorts but their importance to us here is that they can be the triggers for invoking a task. In fact, all tasks are triggered by events. This is the same as saying that goals are established in response to events.

A special case of this is where the task context is tested by an agent for a particular state. The test result is then the triggering event for some task or other.

The definition of ‘Action’ raises a number of issues to do with the agent’s apprehension of other objects and their states, as well as of their own mental states. It has been recognised for some time in human-computer interaction that an agent’s model of the world in which it acts is of crucial importance in designing computer systems which can present appropriate models of themselves (Norman, 1986). There are many notations for so-called ‘conceptual modelling’ (i.e. for modelling the ‘user’s’ concepts). Almost all of these are based on an object-action distinction which states that there are objects in the agent’s world upon which actions can be taken which then transform the object in some way (e.g. Foley and Van Dam, 1982; Moran, 1981). While the various notations each has its drawbacks, this general approach to modelling an agent’s view of the world seems valid.

Importantly, it can be seen from the definition of ‘Action’ that a conceptual model is an intrinsic part of a task model. In fact, to a large extent, an agent’s conceptual model constitutes the context for the tasks it performs. The conceptual model and the task context are not synonymous, however, because an agent to an interaction need not have modelled the context completely and may still receive surprises from aspects of the context it was previously ignorant of.

The definition requires ordered sets of tasks and actions to satisfy a particular goal. The description of these orderings among the tasks and actions for any given goal must be in the form of a program something like the ‘plans’ of HTA (e.g. Sheperd, 1989) or the rule sets of other approaches. Such a program would require all the process description constructs available in programming languages (e.g. sequence, selection, iteration, external interrupts and concurrency) as well as allowing an extra level of indeterminacy to permit users’ choices to be unpredictable if necessary. The program part of a task description will handle events, describe options and sequences and manipulate the state of the context.

Tasks do not happen in a vacuum. Every task has a subject (the agent), an object (the locus for the intended state change) and a context. It is easy to define the context of a task.

In practice, the context is very difficult to define. It is almost impossible to determine the relevant elements of a situation by a priori reasoning and even by observation and interview it is difficult to determine whether the full task context has been identified.

It is largely for this reason that some authors have argued that analyses of human-computer interaction in terms of tasks are inherently flawed (e.g. Heath and Luff, 1991). I have a lot of sympathy with this argument. However, I feel that a task analysis which takes a proper account of context (the ‘situatedness’ of action) is achievable. My reasons are three-fold.

Firstly, the definition of ‘Task’ given above includes the notion of contexts appropriate to their execution. The determination that the agent is in an appropriate context for one set of sub-tasks and actions rather than another is based on the events arising from the world (possibly as the result of tests). In unfolding the execution of a task, the agent is both goal- and event- driven. Thus, rapid goal switching and the appearance of unplanned activity will be the norm in complex or unfamiliar circumstances (e.g. operating a novel photocopying machine, as described in Suchman, 1987).

Secondly, this definition of ‘Task’ will allow agents to shift to general-purpose tasks when the contextual triggers indicate their appropriateness. For example, if none of the sub-tasks known to satisfy the current goal are appropriate, then more general problem-solving tasks can be invoked, much in the style of the SOAR problem-solving technique.

Thirdly, the contexts for human-computer interaction are necessarily constrained by the fact that the computer has been programmed and the states of the program and the events it will generate are, in principle, knowable or designable. Contexts are also constrainable by the conceptual model. That is, the conceptual model for an agent is, to some extent, a model of the task context. In building the conceptual model, therefore, the analyst is able to determine which aspects of the world are going to be important for the interaction to be designed. The design can thus ensure that appropriate events can be monitored and that appropriate tasks exist for them.

The importance of context has led some authors (e.g. Dowell and Long, 1989) to argue that the ‘domain’—the real world in which the interaction is to take place—should itself be modelled to assist in developing a human-computer interaction. The difficulty with this view is knowing how to scope the modelling exercise: What should be included and what should be left out of the domain model? The best approximation to an answer is probably that those things (and only those things) which are in the conceptual model should also appear in a domain model. It is important to note that there is no ‘objective’ domain model that is accessible to us. A user’s conceptual model is, for them, a domain model. It would be arrogant of us as analysts to believe that we are able to see the world in some way more objectively than anyone else. The function of a domain model which we could generate could perhaps be useful as a kind of validation of a conceptual model. In cases where there are no existing users for the tasks to be supported, it is possible that our domain model could stand as a first approximation to a conceptual model.

Tasks unfold in time. All activity has duration. Events as well as the onset and cessation of activity have moments when they occur. The temporal structure of a task may be very complicated. Hartson and Gray (1992) identify several "basic temporal relationships among tasks" namely; "sequence, waiting, repeated disjunction, order independence, interruptibility, one-way interleavability, mutual interleavability, and concurrency" and discuss how these can be incorporated into the User Action Notation (UAN; Hix and Hartson, 1993). It is certain that such relationships exist and that timing is an important issue in modelling tasks. (Unfortunately, Hartson and Gray approach time through the use of a temporal logic, making it—I suspect—difficult for most software engineers to work with their notation.)

In dealing with the rôle of time in the understanding of task, it is important to separate the sequencing of activity (its ordering and overlapping) from the timing of activity (its onset, duration, cessation, etc.). Sequencing is, in general, far more important that timing and more easily handled. It is very common that the interleaving of tasks is managed in terms of which tasks or activities are prerequisites for others, which may be tackled concurrently and which may interrupt others, without reference to specific times or intervals. The program (plan) for a task will need to specify the sequencing rules for the tasks and activities involved but many process languages exist which can handle all that is required here. Occasionally, however, events will happen at fixed, specific times and time constraints may need to be placed on tasks (either in terms of deadlines, or durations, or relative to the timings of other tasks). It is straightforward to conceive of temporal operators that could be added to a procedural task programming language that would provide all the expressive power needed. Such a solution generally has the advantage over a declarative approach (e.g. using an exotic logic) that it is more easily understood by people. It has the drawback that some types of automatic reasoning about and checking of the temporal structure of a task are not possible. The temporal logic approach has the additional disadvantage that building variability into the description (e.g. uncertainty about the onset or duration of an activity—which is a reasonable requirement) complicates it to the point where it is probably no longer viable for any purpose.

Timing and sequencing together describe the overall temporal characteristics of a task. However, the problems of modelling time should not be overemphasised since the need to model timing for most practical purposes is small and the need to manage dialogues involving complex temporal interactions is rare except in a few special tasks.

It is hard to convince the procurers of software that the user interface is important enough to invest extra money in. Unless—or until—there is a revolution in the way procurement works, the only way to make use of the concept of task in the development process will be to embody the description, analysis and design of tasks in simple, fast, robust techniques which deliver quickly-assimilated outputs, geared to fit with established ‘methodologies’. Is it possible to achieve this with the definition of ‘Task’ given here?

Three factors suggest that it is. The first is that the set of definitions provided here suggest that there should be four component parts to a task description. These are:

• the head—a simple statement of a goal to be achieved by the user;
• the body—a (non-empty) set of activities together with any other tasks which together are necessary to achieve the goal statement in the head;
• the program or plan—a description of how to select which action or task to perform on the basis of the state of the context and the events arising from it;
• the context—a model of that part of the world that influences or is manipulated by the task.

This conceptual breakdown looks very close to a conceptual basis for a task modelling language and has some useful properties (such as decomposition and abstraction, a structural as well as a procedural view, and a clear semantics).

The second factor is the ease with which goals can be modelled. It has been argued (Diaper, 1989) that goals should be excluded from task descriptions because they cannot be observed. My own view is that goals are easier to obtain from users than are action descriptions. Although they are not manifest under observation, users can verbalise their goals very easily. In fact, my experience is that, when asked what they are doing, users will normally respond by saying what goal they are currently trying to achieve. Techniques such as ‘laddering’ can then be used to further elaborate the goal structure. Note that the goal structure is identical with the task structure under the definition given here.

The third factor is the linguistic ambiguity surrounding the terms "Goal" and "Activity". It is my experience that people rarely distinguish the two terms when talking about what they do. Thus a description in terms of goals can be interpreted as a description in terms of actions and vice versa (assuming a certain style of expression). This means that the types ‘Goal’ and ‘Action’ can be conflated for practical purposes and need never be distinguished in dealing with users. Their separation is retained in the definition for other purposes such as research and theory development.

The net result of this is that fast, cheap and effective task modelling does seem possible and therefore could be developed for use on real implementation projects.

The practical pressures are for lightweight notations, rapid development of a task description, and accessibility of the task model by end-users. A major requirement of a task modelling technique that often goes unmentioned is that it must be able to make clear the overall task structure so that this can be used to structure functionality in the user interface design.

However, this still begs the question of whether such a description would be acceptable or useful to other members of a systems development project. My experience is that software designers cannot make sensible use of task descriptions of any type. The problem seems to be one of basic viewpoint. A user task description is a view of system operation which is completely different from the software process and data orientation required by the designer.

The practical solution to this problem seems to be to buffer the software designer as much as possible from the task view of the world by progressing the interaction design to an appropriate level before she or he receives it. In brief, this means evolving the detailed interaction design well in advance of the detailed design of the rest of the system and, in effect, presenting it to systems analysts and designers as part of the requirements specification. For this to be effective, the interaction design must be expressed unambiguously in a notation (such as SWN; Windsor and Storrs, 1993) which software engineers can work from directly. This applies to both the database analyst/designer and the application analyst/designer. Working with objected-oriented analysis, design and implementation does not seem to improve matters and does not remove the need for this buffering.

In fact, for over six years now, my colleagues and I have been using a task analysis technique which meets all of the criteria I have listed above. This is a variant of HTA, emphasising goals and with an integrated conceptual modelling technique based (latterly) on OMT. Interestingly, this arose entirely out of the pragmatic needs of various software development projects rather than from a particular theoretical basis. To some extent, the ideas presented here have been ‘reverse engineered’ out of this technique.

As with many other ideas within HCI, the idea of ‘Task’ is multiply defined and poorly defined. To address this problem, I have put forward and discussed a definition of ‘Task’ which I believe says what is important about tasks in human-computer interaction and which is intended to provide a clear statement of what a task is that can be used by developers and researchers alike. It is a definition which fits with my earlier work on defining ‘Interaction’ and so is consistent with a growing conceptualisation for the field of HCI. A valuable consequence of this attempt would be the generation of a debate within the HCI community as to the meaning of this important term.

Annett, J. and Duncan, K.D.. Task Analysis and Training Design, Occupational Psychology, 1967, 41, 211-221.

Bass, L. and Coutaz, J.. Developing Software for the User Interface. 1991, Addison-Wesley.

Boehm, B.W.. Software Engineering Economics, 1981, Prentice-Hall, N.J..

Card, S., Moran, T.P. and Newell, A.. The Psychology of Human-Computer Interaction. 1983, Lawrence Erlbaum Associates.

Diaper, D. (Ed.) Task Analysis for Human-Computer Interaction, Ellis Horwood Ltd., Chichester, England, 1989.

Dix, A., Finlay, J., Abowd, G. and Beale, R.. Human-Computer Interaction. 1993, Prentice Hall.

Dowell, J. and Long, J.. Towards a conception for an engineering discipline of human factors. Ergonomics, 1989, 32, 1513-1535.

Foley, J.D and Van Dam, A.. Fundamentals of Interactive Computer Graphics. Addison-Wesley Publishing Co., Reading, MA. 1982.

Hartson, H.R. and Gray, P.. Temporal Aspects of Tasks in the User Action Notation. Human-Computer Interaction, 1992, 7, 1-45.

Heath, C.C. and Luff, P.. Collaborative Activity and Technological Design: Task Co-ordination in London Underground Control Rooms. Proc. E-CSCW '91, 1991, 65-80.

Hix, D. and Hartson, H.R.. Developing User Interfaces: Ensuring Usability Through Product and Process. John Wiley & Sons Inc., NY. 1993.

Johnson, P., Johnson, H., Waddington, R. and Shouls, A.. Task-Related Knowledge Structures: Analysis, Modelling and Application. In D.M.Jones and R. Winder (Eds) People and Computers: From Research to implementation. 1988, Cambridge University Press, 35-62.

Moran, T.P., The Command Language Grammar: A representation for the user interface of interactive computer systems. International Journal of Man-Machine Studies, 1981, 15, 3-50.

Norman, D.A.. Cognitive Engineering. In D.A. Norman and S.W Draper (eds) User-Centred System Design: New Perspectives on Human-Computer Interaction. Lawrence Erlbaum Associates, 1986, 31-65.

Payne, S.J. and Green, T.R.G. Task Action Grammars: A Model of the Mental Representation of Task Languages. Human-Computer Interaction, 1986, 2, 93-133.

Shepherd, A.. Analysis and Training in Information Technology Tasks. In D. Diaper (Ed.) Task Analysis for Human-Computer Interaction, Ellis Horwood Ltd., Chichester, England, 1989, 15-55.

Storrs, G.. A Conceptual Model of Human-Computer Interaction? Behaviour and Information Technology, 1989, 8(5), 323-334.

Storrs, G.. A conceptualisation of Multi-Party Interaction. Interacting with Computers, 1994, 6(2), 173-189.

Suchman, L.. Plans and Situated Actions. Cambridge University Press, Cambridge, England. 1987.

Sutcliffe, A.. Some experiences of integrating specification of human-computer interaction within a structured system development method. In D.M. Jones and R. Winder (eds), People and Computers IV, Cambridge University Press, Cambridge, England, 1988, 145-160.

Windsor, P. and Storrs, G.. A Practical User Interface Design Notation. Interacting with Computers, 1993, 5, 423-438.