Posted by Like every self-respecting human-computer interaction (HCI) lecturer, I introduce task analysis or the technique of analysing how people perform a task or job, to my students a couple of weeks into a given course. Each time I am aware that I fail to get excited about task analysis and so give it a bad press.
This is because I was taught to program as an undergraduate at Liverpool John Moore’s University (LJMU, then Liverpool Polytechnic) by a group of very good lecturers and researchers, in particular John Pardoe, Melvin King and Stu Wade. They used literate programming as the basis of their teaching methods.
Literate programming was first suggested by Donald Knuth in 1984 with the aim of changing attitudes towards programming. He proposed that instead of giving a computer a list of instructions, it was better to explain to human beings what we want a computer to do. This meant generating good designs and good documentation. At LJMU they combined the idea of literate programming with Niklaus Wirth’s Stepwise refinement design method and wrote a fantastic programming Pascal-based support environment which taught students to perform good design and appreciate self-documenting programs.
As an undergraduate I was taught to think about program input and output, code presentation and documentation: Could someone else pick up what I had done and understand it? And I appreciated the self-generating diagrams (flow charts) and documents. I hope the software is still in use, not least of all because Pascal is a good educational tool to introduce students to programming and to learn proper programming skills (Java isn’t – but that is another blog). The downside for me is that with such a good grounding in programming and design methods when I first looked at task analysis and the hierarchical task analysis diagrams (flow charts which are a bit more complex, hence the hierarchy) it seemed a derivative method which would only serve to confuse the person using it.
Theoretically there is nothing wrong with a derivative method because HCI often borrows from everywhere else, after all why reinvent the wheel? However, task analysis diagrams are useless when compared to literate programming/stepwise refinement diagrams because task analysis charts are trying to describe how a user goes about performing a specific task which may include using a computer.
The purpose of task analysis, in the main, is to understand how a user does something. However, if you show the flow chart back to the user or your client you can guarantee it will be a turn off because humans who are not computer scientists don’t want to look at a diagram that seems to be computer domain specific. A flow chart traditionally models information flow – hence its name. Placing human activities, often goal orientated tasks, into boxes meant for modelling information flow doesn’t seem the best way of trying to capture and describe human behaviour. There is no clear indicator of input or output, and there is no clear division of tasks which occur computationally and in the real world. If you interview five to ten users and you may well get five to ten unrelated diagrams back with no commonalities either. There is no indicator either of what would need to exist for the user to be better supported during this task.
In a nutshell, task analysis encourages a great mish-mash of ideas and provides very little help to the designer. This is supported by many articles on task analysis saying: ‘There is no wrong or right answer’, ‘There is no one way of performing task analysis’, and my favourite ‘It may not be suitable for all contexts’. The examples most textbooks use to illustrate task analysis don’t help either: making the tea or hoovering the house are not about to be automated, don’t need a computer, and are very different from inputting data into a program and getting data out of it. During lectures, I have seen great rows break out about tea-making: cup or pot, milk in first or last (often students think is a useful way of distracting the lecturer from making them think anymore about task analysis. If only they knew).
The results of task analysis theoretically help developers to write manuals and tutorials, detailed interface designs – particularly ordering subtasks in interface design, and scenarios for designing interfaces. However, these three areas are wide ranging and need many inputs not just one flow chart that isn’t a natural description of how a human behaves. During consultancy I have never used a task analysis diagram.
This leads me to conclude that task analysis is really just useful for exam questions. You can get students to read a text and then get them to draw some diagrams – which isn’t what you would do in the real world, as you would get the students to talk to users (I got them to do that once and they didn’t like it and wanted me to provide them a summary of everything the user had said, *sigh*)- and it becomes an ‘easy’ question to ask and mark.
If the students have been paying attention and a) know what task analysis is, and b) can show that they can draw a flowchart moreoreless, then as a lecturer you have asked them to provide some book learning in a) a definition of task analysis, and b) application of learning, and you get a pat on the back for constructing good exam questions from the external examiner.
That just leaves us struggling through the lecture where students are first introduced to task analysis and have to force all sorts of unsuitable information into a flowchart. Apologies to all students past and future!
One comment