15. task models

The exercises for this chapter, like the chapter itself, concentrate on real world rather than computer examples. This is largely because task analysis of current computer systems depends on the particular systems available.
If you are teaching a course, and want to set a task analysis exercise for students, it could be of the general form:

  • Observe use of the . . . computer system.
  • Perform a task analysis (of some kind).
  • To what extent do you think the way people perform these tasks isdetermined by the system and to whatextent by the fundamental aspects of the task?
  • Does the system's menu layout, etc., support the tasks it is used for? In particular, are frequent task sequences easy to perform?
  • Suggest potential improvements, both incremental changes and radical redesigns of the system.

The details of the question can, of course, be varied depending on the system and students can be directed to particular subsystems where you have observed problems.


The following is a list of objects found in one of the authors' kitchens:

teapot, mug, soup bowl, plate, spoon, table knife, cook's knife, fork, saucepan, frying pan, kettle, casserole, fish slice, tin opener, baking tray, scales, mixing bowl, glasses, jugs, corkscrew, rolling pin, ladle, egg cup, chopping board.

Produce a taxonomy using the TDH notation of these objects. Does it obey the TAKD uniqueness rule? Compare your answer with someone else's. (Note: the authors had great difficulty with items like the corkscrew, which did not fit easily into any generic category - perhaps you did better.)


As the authors had already produced a partial taxonomy, we interviewed two domain experts (cooks). They were asked to describe how they would group and classify the kitchen items. They were explicitly told (and reminded) that they could have multiple classifications and put the same item into several categories. The authors then cast their answers into TDH notation.

One of the subjects was a doctor and used to medical taxonomies of disease. Despite stressing the looseness of the classifications, he insisted on a complete taxonomic tree (Figure Ex15.1.1).

kitchen object XOR
|__  preparation XOR
|    |__  pre-preparation XOR
|    |    |__  opening
|    |    |         tin opener, cork screw
|    |    |__  measuring
|    |              scales, (measuring) jug
|    |__  'proper' preparation XOR
|         |__  active
|         |         rolling pin, cook's knife, (cook's) spoon
|         |__  passive
|                   mixing bowl, chopping board
|__  cooking XOR
|    |__  passive
|    |         teapot
|    |__  active XOR
|         |__  external power
|         |         saucepan, frying pan, casserole, baking tray
|         |__  internal power
|                   (electric) kettle
|__  serving XOR
     |__  serving
     |         fish slice, (serving) jug, ladle
     |__  eating XOR
          |__  active
          |         spoon, fork, knife}
          |__  passive XOR
               |__  food
               |         egg cup, soup bowl, plate
               |__  drink
               |         mug, glass

Figure Ex15.1.1 - TDH taxonomy produced by first subject

As you see all his branches are XOR branches. On discovering that 'jug' had to fit in two places in his taxonomy, he split it into 'serving jug' and 'measuring jug'. This emphasises the need for the task analyst rather than the domain expert to actually draw up the taxonomy!

As it is a true tree it clearly does not satisfy the uniqueness rule, but the only way it could is to invent spurious new categories. One could under 'opening' add categories for 'bottles' (containing corkscrew) and tins (containing tin opener), but this would not improve clarity.

If the first subject was a stickler for precision, the second subject preferred broad categories. Figure Ex15.1.2 shows her initial classification.

kitchen object OR
{__  things for making tea
{         teapot, mug, kettle, spoon
{__  things for eating meals
{         soup bowl, plate, glasses, egg cup
{__  cutlery for meals
{         spoon, table knife, fork
{__  cutlery for cooking
{         spoon, fork, fish slice, tin opener, table knife,
{         corkscrew, rolling pin, ladle
{__  things for making meals
{         saucepan, frying pan, casserole, baking tray, scales,
{         mixing bowl, jugs, chopping board
{__  things for serving meals
          jugs, casserole, fish slice, corkscrew, ladle, spoon

Figure Ex15.1.2 - Initial version of TDH taxonomy produced by second subject

We wanted to put some additional structure on this and so, after some discussion, the subject agreed that her basic distinctions were those of function ('making meals' etc.) and between cutlery and non-cutlery. Using these to form an AND branch, we obtained Figure Ex15.1.3.

kitchen object AND
/__  material XOR
/    |__  cutlery
/    |         spoon, table knife, fork, fish slice, tin opener
/    |         corkscrew, rolling pin, ladle
/    |__  non-cutlery
/              teapot, mug, kettle,
/              soup bowl, plate, glasses, egg cup,
/              saucepan, frying pan, casserole, baking tray, scales,
/              mixing bowl, jugs, chopping board
/__  function OR
     {__  making tea
     {         teapot, mug, kettle, spoon
     {__  cooking meals
     {         spoon, fork, fish slice, tin opener, table knife,
     {         corkscrew, rolling pin, ladle,
     {         saucepan, frying pan, casserole, baking tray, scales,
     {         mixing bowl, jugs, chopping board
     {__  serving meals
     {         jugs, casserole, fish slice, corkscrew, ladle, spoon
     {__  eating meals
               soup bowl, plate, glasses, egg cup,
               spoon, table knife, fork

Figure Ex15.1.3 - Refined version of TDH taxonomy produced by second subject

This taxonomy does not obey the uniqueness rule either; for example, fish slice and ladle always appear together. In terms of KRG they are both:

     kitchen object/material(cutlery)/
                             function{cooking meals,serving meals}/

The TAKD purist might demand extra categories to fulfil the uniqueness rule. However, the authors would recommend that students simply be taught to recognise the rule and use it as a heuristic.

It is interesting that both domain experts focused on the functional view of the items, just as the authors did in the book. This suggests that it is indeed a generic way of classifying kitchen objects and would thus be a good candidate for classification in a catalogue or menu system. The second subject also noted that her original breakdown was inspired, not so much by the function per se, but by where the items were stored in her kitchen - itself determined largely by function. This is perhaps the physical equivalent of a menu system!



Complete the tea-making manual in Figure 15.7. Do you think it would be useful? Think of situations where such a manual would be helpful and where a more conceptual manual would be better.


Although a manual for tea making might be regarded as a little extreme, such manuals are useful in several situations. You could pose this exercise, together with the initial task analysis, for different domains where more of the following situations are pertinent.

The first situation where a procedural manual is useful is for the absolute novice who has no idea of the conceptual background. This might be a first-time user, or when an activity is performed very infrequently. A good example of the latter is the installation of computer equipment, which most users perform only once every couple of years. Similarly, recipe books are laid out in a highly procedural fashion, although unfortunately not always clearly:

Beat the egg whites until they froth,
then put them into a ramekin.
While beating the egg whites, slowly add the white wine.

The second situation where a procedural manual is useful is where there is some sort of safety-critical aspect, and erroneous decisions, even those carefully considered, can be disastrous. Often, in such a situation, the additional stress can cloud judgement and make it far safer to stick to a predetermined drill. Emergency procedures in large chemical or nuclear installations are an example of this -- when an emergency arises the operators are expected to stick closely to the set procedures. The accident at Chernobyl came about in part because the operators felt that they knew enough to override the rule book. Reading a manual in such circumstances may be too time consuming, but an HTA can be used to train the operator to respond automatically. The use of HTA for military training is largely in this vein.

Thirdly, the situation may not be safety critical, but it may be time critical. Much analysis may have gone into discovering the most efficient way to perform a task, and that way is then taught, by rote, to the operators. Although this form of time and motion approach is less likely to be useful in an information intensive job than in a factory (if there!), there are jobs, such as telephony, where it is still important.

Finally, the user may not have sufficient knowledge to understand why a process works, but can follow a set of instructions. This may relate either to the complexity of the task or to the skill of the operator. If one were teaching kitchen craft to mentally handicapped people, then just such a procedural description of tea making would be required.

The problem with such procedural manuals is that they give the operator no real feeling as to why the tasks are performed in the way they are. Whether such a manual is preferred by a novice user depends very much on the user's personality. Some people prefer to have a set of instructions to get them started, whereas others find it very difficult to use something without some sort of conceptual understanding.

The procedural manual really comes unstuck when the set of tasks considered is not complete. When faced with a radically new task the user must understand enough of the domain to perform it ad hoc or to modify an existing procedure. One frequent cause of entirely new situations is unforeseen breakdowns of equipment. For example, if the kettle was broken, one could then abstract that the real reason for boiling the kettle was to heat water and that this could be performed by heating a bowl of water in the microwave oven. Such a modification of the procedure is not even suggested by the procedural manual.



Figure 15.1 shows a textual representation of an HTA description of vacuum cleaning. Present the same information in a diagrammatic form


This is given in Figure Ex15.3.1. In fact, this uses the revised version of 'plan 3', but the choice of plan makes no difference to the structure of the diagram.

Figure Ex15.3.1 - HTA diagram for vacuum cleaning a house



(Converse to above) Figure 15.6 uses an HTA diagram to show the actions in which a tractor is involved; show the same information textually.


0.    life cycle of tractor        
    1.    maintenance            
    2.    cultivation            
          2.1.    connect implement    
                  2.1.1    fix harrow  
                  2.1.2    fix plough  
          2.2.    drive to field       
          2.3.    cultivate field      
          2.4.    drive to shed        
          2.5.    put away

Plan 0:    as required --- 2   
           when tractor breaks down --- 1

Plan 2:    2.1 -- 2.2 -- 2.3 -- 2.4 -- 2.5

Plan 2.1:  one of 2.1.1 or 2.1.2 depending on job



Observe an office, note the actions performed and the objects used depending on the available equipment; use different recording techniques as described in Chapter 9. Then use the different task analysis techniques to structure your findings. (Note: this could be a group project.)


The easiest starting point is simply to go around the office noting down what is there:

typewriter, corrector fluid, desk diary, pen, pencil, scissors, envelopes, paper clips, typing paper, post-it notes, telephone, telephone directory (internal and external), filing cabinet containing folders, clock, wall calendar.

This list can then be used to begin to build either a knowledge-based or an entity--relation description. However, the latter will also require at least a list of actors. In a university office this might include the following:

secretary, lecturer, student (undergraduate), research student, research staff, administrator

However, the roles that they take may not be simple. For example, we may find that a lecturer comes into the office to use the typewriter. That is the lecturer acts in the role of typist.

Neither of these descriptions can be complete, nor can an HTA begin, without a list of activities. This can be obtained in two main ways. First, students can simply make an unstructured list of all the activities they see, and then add structure to it. Alternatively, they can follow specific tasks noting what is done in what order. In the latter case, they are encouraged to write the list of activities in a purely sequential manner -- they are observing. Only later will they build upon this a hierarchical interpretation.

It might obviously cause severe inconvenience if all the members of a class were to interview the office staff. However, to gain first hand interview experience, some domain expert can be invited into a class or lecture to talk about their work and be questioned about it. Alternatively, students could make their own notes from a preprepared videotaped interview.

If a question of this sort is used as an assessment, then we would suggest that students hand in not just the completed task analysis, but intermediate notes and representations. The most important thing in determining the effectiveness of their analysis is the care with which they carried out the original observation and subsequent working.



This exercise is based on the mobile phone scenario on the web at: www.hcibook.com/e3/scenario/phone/

A user interface designer analyses Andy's behaviour with his original phone and realises that both scenarios A and B are part of a general pattern as shown in the Hierarchical Task Analysis (HTA) in Figure 15.8.

(i) Complete the HTA for phoning using the original phone taking into account scenarios A and B only and briefly describe your solution.
(ii) Do a complete HTA for phoning using the new phone based on scenario C only
(iii) You will find that scenario C (and hence your solution to part (ii)) does not quite fit into the general pattern in Figure 15.8.

Discuss whether the solutions to (i) and (ii) can be modified to emphasise their common features and whether this would clarify the overall task description.

Rough HTA
Figure 15.8. Rough HTA

answer available for tutors only

(i) This part is mainly a fleshing out of the 'find number' subtask. Students may choose to use the textual form of HTA and this is acceptable.

  • Simple answer for plan 1 would be one or other, but some students should think a bit more about what this is really like for users.


(ii) Main subgoals below

  • but students should either flesh out 2.1 and 2.2 or justify that this is unnecessary


(iii) Big difference is that the dialling of the number gets folded into finding it.

  • One solution is to transform the view of the original tasks (see below)
  • Alternatives may be to have a conditional sub taks 'dial number if necessary'
  • May also note here or earlier that waiting may be worth including as sub-task
  • But should be asking whether these are sensible tasks from a user perspective



EXERCISE 15.7 [extra - not in book]

Look at the recipe for Chocolate Biscuit Cake. Produce a hierarchical task analysis (HTA) based on it. The recipe considers only the most basic actions and you will have to determine higher level tasks. Also, the recipe may give a specific order for some sub-tasks which could in fact be performed at the same time or in a different order. Finally, the recipe may omit various details assuming that the cook will know what to do.

Expand some parts of the recipe to as much detail as possible.
Make a list of all the things you need to know about in order to follow the recipe
If possible, compare your answers with those of others. Did you notice different things?
NB It makes a very nice dessert.

Chocolate Biscuit Cake

Metric Imperial
225 g plain chocolate 8 oz plain chocolate
225 g butter 8 oz butter
2 eggs, beaten 2 eggs, beaten
25 g caster sugar 1 oz caster sugar
225 g digestive biscuits 8 oz digestive biscuits

Grease a 15 cm (6 in) cake tin with a detachable base. Break up the chocolate and put it in a bowl over a saucepan of simmering water to melt. Melt the butter in another pan over a low heat. Beat the eggs and sugar together in a bowl. Pour the melted butter in slowly, beating all the time. Now blend in the melted chocolate. Break the digestive biscuits into small pieces and fold them into the chocolate. Put the mixture into the cake tin and chill overnight, in the refrigerator. Turn out of the tin and serve.

answer available for tutors only

open-ended investigation


EXERCISE 15.8 [extra - not in book]

(Cross-refer to Chapter 9) This is a extended design exercise in two parts. The first part uses information from users to develop a design for a mobile phone. The second part uses different evaluation techniques to assess the design.

There are two aims: to demonstrate how the views of users can be incorporated into design and to demonstrate the different information that can be gained by using different evaluation methods.

You have been asked to design a mobile phone taking into account the user views expressed below, determined from market research studies.

There are a number of factors that have to be considered in the design, ranging from the way information is entered into the system and the manner in which it is presented back to the user, through aesthetic judgements to the functionality that the system should offer.

1. Design

Read the user responses given below and then analyze them under the following headings:


You need to determine the tasks that users wish to perform with the phone, and how they want to go about performing those tasks. You need to decide what features your phone should offer and what are dispensable. You are constrained by real-life costs and so will have to trade off size for weight and battery life, cost against functionality, and so on.

Try to identify the real issues that people consider when using a mobile phone. Try to see what factors will influence their decision about which phone to buy. It is these that must motivate your design. Make a list of the features you feel your phone must have.


How are you going to present all this information to the user? What style of output is most suitable? What is the best way to interact with it? Will you present all the information at once? What input characteristics will your phone have: how will numbers be entered, functions accessed, and so on?

Having thought about these things, consider that you are also trying to keep the electronics inside the phone as simple as possible. Remember too that people will not carry a manual for their phone around with them, and so they will need to be able to understand what to do, or to be reminded by the interface itself.


Consider issues of overall colour, size, shape, texture; of button spacing, layout, colour and feedback; display size and placement; information display.

You will use this analysis as the basis of your design. Modelling techniques such as task analysis can help to clarify this, which will in turn make the process of design easier.

Having decided upon all the relevant information, now design your phone. You have to produce two views of the phone.

  • The first is a picture of the phone as it appears to the user, with no additional labelling - make this as high quality as you can. Imagine it is the sort of picture that would appear in a brochure advertising the phone.
  • The second view is of the same phone seen from above.
  • An additional set of pictures of parts of the phone should also be provided that would enable you to run through a typical interaction with a prospective user, showing the display state when they perform certain actions to achieve a certain function.

Either do all of these designs separately on paper, using colour, shading and different viewpoints as appropriate, or utilise OHPs to overlay the basic design. This is particularly useful for the second view of the phone as it allows you to update the display state without requiring redrawing of the rest of the phone.

Again, modelling techniques can help in the development of an effective dialog. Consider, for example, using a dialog notation to describe the details of your interface or performing a GOMS analysis of the main tasks supported by your design.

Mobile Phone: User Responses

A group of people were interviewed to obtain their views on the features they would expect to find in their ideal mobile phone. Some of the people currently use a mobile phone, others do not. Given below are the (edited) texts of their responses.

A. 'I want to keep track of the number of calls that I make, and the cost of the calls. Since I use the phone for business it has to be small but powerful but can't cost a lot to buy. I don't want to fuss with that stupid aerial thing that you have to flip up in order to use it and I want to be able to keep ringing people back if they're busy - as I said it has to be hand-held but that's it really.'

B. 'Ohhh - a mobile phone! Well, it just has to ring people and let people ring you, doesn't it.'

C. 'It must be able to store telephone numbers as I won't have my telephone book with me, but I dunno how I'd search for the numbers - perhaps a pad on which you could write them down would be a good idea - no that's daft really isn't it, I mean it's supposed to be electronic, what about a volume control for ringing? I remember someone's phone going off in a meeting. It was really loud and she was so embarrassed .....what about the buttons, will it have press buttons or a dial? Oh I can decide - well I like the dial personally, I think it's aesthetically pleasing, but some people like buttons. I dunno really. Running them costs a lot of money so I suppose I'd like to be able to tell how much I'd spent that day on calls - sort of get my bill as I go along, I suppose. Will I be able to turn it off? Oh - I have to decide, do I? Well, I suppose I should have it with me and on all the time but what if I didn't want to be interrupted? So I suppose I'd want to turn it off ..... but then I may miss important calls - can I have an answering machine built in as well or something so that it answers my calls if I'm not there - that would be nice.'

D. 'I wouldn't use one ever - yuppie toy!'

E. 'Well, the buttons would have to feel nice as I hate those plasticky tacky ones you get on those cheap phones. It's difficult to tell when the button has been pressed sometimes. Some sort of display would be good - I suppose it should have information on the status of things - battery, maybe, and the signal strength, the number I'm calling, the previous numbers so that I can scroll back and get them, and perhaps an address book thingy that has names and addresses and telephone numbers in. Hmmm, that's a bit bulky, right - I'd want it to be pocket-sized too. Oh, and the batteries should have to last for ages and ages and I want to be able to charge it up anywhere like in the car and so on.'

F. 'Oh - I'd never have one because what if I lost it? It's not the cost of the phone that's the problem, it's that someone may ring up their friend in Australia and I'd have to foot the bill. It would be okay if only I could use it.'

G. 'Wow - mobile phones are great - I want one that rings people up, takes messages, will allow me to send faxes and receive them, will act as a calculator as well - I mean there's all those number buttons already, right? - and an address book and small word processor - it's got to have a display and things, right? so it could also be a personal organiser and interface to PCs and Suns and Macs and things and it must be small; that's for certain, it has to be small and the battery has to last for a week or so without being recharged and handheld - no, I said that - errrm ... that's it. Oh, and I want to use it with the interface bit so as I can read my email on the Suns when I'm away and stuff.'

H. 'Easy: 1. see the number I'm ringing. 2. be able to redial easily when a number is busy. 3. see the battery strength. 4. see how much it's cost me. 5. have nice buttons to press with good feedback. 6. not have to re-enter all a long number if I make a mistake. That's all'

I. I'd like a system that has an address book in it, but it doesn't have to be too powerful. Then I want to be able to see what number I'm ringing and re-ring it if necessary and see how much the calls have cost. A good aerial will be needed because good reception is really important. A way of barring calls to international numbers would be good and a way of barring others from using it would also be nice. I'd want to turn it off occasionally but I dunno what would happen if anyone tried to ring me.'

J. 'I like them, especially the grey ones - they're better than the black - and the pretty light that comes on, that's good too - dunno what it's for though.''

K. 'I don't like them - because I'm a bit deaf they're too quiet for me and I can't hear what people are saying.'

L. 'Ha! what would be nice is a phone with not too many buttons! They all have too many buttons nowadays and I hate that. Keep it simple, I reckon.'

M. 'I don't understand them. I never know which button to press to get the phone to ring and which to press to stop a call, and I can never work out how to answer it either - do you just pick it up or what? And what are the letters on the number buttons for? You know -- the 1 has 'abc' on it and so on?'

N. 'What's a mobile phone - a cordless one? Oh, one of those things. Naw, I don't want one of those - they're like half a housebrick.....oh, I can choose, can I - well, I just want the same as I've got at home - small, you know, but having it portable. That's all I want.'

2. Evaluation

The second part of this exercise concentrates on the evaluation of your design and looks at two different evaluation methods: heuristic evaluation and think aloud.

The first evaluation method is 'heuristic evaluation'. You will evaluate your design against a set of general usability criteria (laid out below):

  • visibility of system status
  • match between system and the real world
  • user control and freedom
  • consistency and standards
  • error prevention
  • recognition rather than recall
  • flexibility and efficiency of use
  • aesthetic and minimalist design
  • help users recognize, diagnose and recover from errors
  • help and documentation

These criteria are discussed in more detail in Section 9.3.2

The aim of the heuristic evaluation is to debug the design; to highlight the points in the design that are inconsistent or likely to cause users problems.

If you can, also exchange designs with a colleague. Evaluate each other's designs using all of the design material and the usability criteria given above. During your evaluation, consider if there are other general criteria that are important considerations for this particular example; if so, include them. You are aiming to see where the design is successful and where it fails; it may assume too much, or too little, it may not offer any feedback, or present an unclear view of what is happening. The user may be expected to remember too many things at once, or there may be different ways to do similar things.

Make notes of your evaluation.

At the end of this stage, you should have done a heuristic evaluation of your design and, if possible, have received an independent evaluation of it. Compare these evaluations, collating similar problems and resolving differences, until you have an accurate summary of the evaluation.

Complement the heuristic evaluation with the observational technique of think aloud. For this you need one or more people to help you.

As an evaluator, spend a few minutes thinking of some scenarios and tasks for the user to perform. For example, to look up a telephone number, to meter a call, or to dial a number. Include some complex tasks as well as some simple ones. Ask the user to step through these tasks using each design, 'thinking aloud' as they do so - describing what they think is happening, why they take an action, what they are trying to do. Take notes on the user's actions, comments and any problems. The fuller the detail in the protocol, the better.

Note to the 'user': Follow the evaluator's instructions. Try to give as much information as possible. People tend to say less when they are unsure what to do, but this is the time that the evaluator needs to know most. Go through explaining which buttons you would press and when, giving the designer the chance to show you what, if anything, would happen to the display.

Look at the results from the heuristic evaluation and the think aloud. Notice where they highlight problems in the design. Also look for instances in which the design allows tasks to be easily accomplished. Compare the two techniques and note anything which is identified by one technique and not the other.


Reappraise your design carefully in the light of the evaluation process. Carefully look at things that cause confusion, at the functions that are there but may never be used, and comments your users made about the good and bad points of your design. Try to come up with a new version of the phone. It should incorporate all the good features of the previous prototype, while avoiding all the problems that it may have suffered. Having decided, produce a final labelled drawing of the ideal phone.

answer available for tutors only

extended project


EXERCISE 15.9 [extra - not in book]

For each system, identify three representative tasks that need to be supported.

1. A system to provide travel information to coach passengers
2. An information system to support an estate agency
3. A virtual lecture theatre
4. A World Wide Web search engine.
5. An information kiosk at Crufts to help people choose an appropriate breed of dog for their lifestyle.
6. An electronic point of sale system for a large supermarket chain.
7. A video conferencing system to support admissions interviews for a virtual university.
8. An electronic banking system running on the World Wide Web.
9. A library information system
10. A web based book shop.
11. A cooperative editing tool to support co-authors
12. A custard dispenser on a cake production line.

answer available for tutors only

1. A system to provide travel information to coach passengers
find bus time, find route information, find ticket price
2. An information system to support an estate agency
search for suitable property, add property to listing, record sale
3. A virtual lecture theatre
listen to lecture, present lecture, ask question
4. A World Wide Web search engine.
find specific site, find sites on search terms, browse subject areas, register site
5. An information kiosk at Crufts to help people choose an appropriate breed of dog for their lifestyle.
enter constraints, find breed details, find breeders
6. An electronic point of sale system for a large supermarket chain.
register item, total bill, remove item from registered
7. A video conferencing system to support admissions interviews for a virtual university.
run student -staff interview, demostrate course materials, review interview
8. An electronic banking system running on the World Wide Web.
check account balance, transfer money, deposit money
9. A library information system
find title, find availability of book, check items on loan
10. A web based book shop.
browse titles, buy book, order book
11. A cooperative editing tool to support co-authors
comment on text, edit text, incorporate multiple edits
12. A custard dispenser on a cake production line.
adjust dispense quantity, stop dispensing, monitor consistency


EXERCISE 15.10 [extra - not in book]

How would you determine the task requirements of a system?

answer available for tutors only

Information on task requirements would be gathered by some or all of 1. analysing documentation outlining current procedures 2. observing current execution of task, 3. interviewing/questionnaires to users, 4. examining existing similar systems. Ideally several different sources of information would be used.


EXERCISE 15.11 [extra - not in book]

This question relates to the train both scenario.

The figure below shows an incorrect Hierarchical Task Analysis for the task of catching a train using the train booth described in the Train Booth Example.

  1. List any errors/omissions. (Note tasks 1, 3 and 4 are deliberately not expanded to focus on use of train booth)
  2. Fix the errors/omissions found

incomplete HTA

answer available for tutors only

  1. Missing Plan 2.
    Task should be a sub-task of 2.1.1 in sequence after; this is an example of sub-task / sequence confusion.
    We have a 'remove' action for the Gold Card but no corresponding 'insert'.
  2. Corrected diagram (indicative) below.
    And plans (indicative):
       Plan 2.
          do 2.1 – 2.2 – 2.3 – 2.4
       Plan 2.2
          do 2.2.1 – 2.2.2
       Plan 2.2.1
          do –
       Plan 2.3
          do 2.3.1
          if OK do 2.3.2, 2.3.3

revised HTA

Individual exercises

ex.15.1 (ans), ex.15.2 (ans), ex.15.3 (ans), ex.15.4 (ans), ex.15.5 (ans), ex.15.6 (tut), ex.15.7 (open), ex.15.8 (open), ex.15.9 (tut), ex.15.10 (tut), ex.15.11 (tut)

Worked exercises in book


Produce a high-level hierarchical task analysis showing how you would find information on a website. Assume the site has a search facility as well as normal links. [page 518]


Consider the activity of making a telephone call. Record the actions in an HTA diagram or textually. Start off simply assuming you know the number to dial, but then add more complicated situations: finding the number in an address book, or what to do when the number is engaged. [page 530]


The act of looking up a person in an address book or telephone directory is itself quite complicated. Get several friends to look up words in a dictionary. Observe closely their methods. You will probably have to develop shorthand notations to keep track of what pages they visit. Compare the strategies used by the different people. If they differ, try to abstract out the common parts of the task and the variable parts. If you have a computing background, try to attempt to classify their methods in relation to known search algorithms: binary chop, linear search, etc. [page 533]

  • a worked exercise