Tasks are a central concept in understanding the users and what they are doing. When it comes to develop computer systems for work, what users are doing can be describe as work tasks. Outside work, people are of course, also performing different tasks, for example sending sms with their mobile phone.

The questions that the task analysis should give answers about are of the following types:

1. Goal. Why is the user carrying out a specific task?
2. Frequency. How often is the task been carried out?
3. Time. How long time does it take to perform the task?
4. Environment/context. Where is the task carried out? In what context is the system being used?
5. Subtasks. What steps or operations have to be done in order to carry out the task?
6. Organization. Are the users cooperating with others?
7. What technical aids are necessary to perform the task; tools, computer applications, networks, phones, paper forms, etc?
8. Are there critical steps or 'bottlenecks' in the work procedures that makes the task more difficult?
9. How can the whole situation and the information support be improved?

In order to develop a usable system, it's essential to do a detailed task analysis. With that analysis as basis, it's possible to describe what tasks or functions the new systems have to support. If a function is hard to use or not supporting a users task, it will probably not be used at all, which is waste of the programmers time in the project. A widespread problem is that the system contains too many functions, which results in that the user has a trouble with finding the functions they really need. In these cases, the developers have not properly understood what tasks are essential and how the system should support the users in performing them.

There are several different methods for task analysis. The most common methods are structured interviews and observation interviews. Some important things to remember in interviewing users are:

• Ask about specific and authentic situations and things in the users work.
• Avoid abstract questions about what they believe how their working conditions can change and improve.

Complement with observations of users in work. Some examples of questions:

• "Why are you doing this?" - relate to goals.
• "How are you doing it?" - divide the work into subtasks.
• "Why are you not doing it in another way?"
• "Does it get wrong sometimes?"
• "What happens if it goes wrong?"

The results from interviews and observations are compiled and structured. There is a wide range of different methods to use in this part of the analysis. On one side there are 'macro methods' where the whole system in terms of organizational, social and technical aspects is taken into consideration. On the other side there are 'micro methods', where single tasks are divided into smaller cognitive units, for example pressing a button.

Generally an analysis contains the following steps:

• Always define an overall goal with the entire user-system interaction.
• Define the users' goals and sub-goals.
• Define the tasks = ways to fulfill the goals.
• Define what information the users need to fulfill their goals.
• Divide to goals and tasks 'in breadth' first and identify common parts, then divide each goal and task in depth.
• Stop the division of tasks, when they reach single work operations.
• Preferably, use pen and paper, for example sticky-notes, in the task analysis.

Together with the user analysis, the task analysis is the foundation for the rest of the design process. The course literature (Preece, 1995) describes two major approaches to do task analysis: Hierarchical Task Analysis (HTA) and cognitive task analysis. In the next section, we give an overview of HTA, the rest is in the book by Preece et al. We also give a short introduction to an alternative way, Cooper's Personas, which where introduced in the previous part of the lesson.

Hierarchies are important structures from a cognitive perspective. Problem solving strategies can often be organized hierarchical, where tasks are divided into less complex subtasks, and finally reach a more or less atomic operation, such as pressing a button.

The purpose of hierarchical task analysis, HTA, is to describe the users' tasks structured in a hierarchical of goals, tasks, operations and plans.

• Goals - the desired state of the system.
• Tasks - how the goal can be fulfilled.
• Operations and actions - what the user does to perform the task. This is the smallest level of description of the user's actions.
• Hierarchies of tasks and subtasks
  • Plans - describes under what conditions that a...
  • ...subtask shall be performed,
  • Stop criteria - how deep a task shall be divided into subtasks.

An example of HTA (from Preece, Rogers & Sharp, 2002, Interaction Design):

Imagine that you want to borrow a book in the library, this is your goal. To fulfill this goal, you have to perform a number of tasks, in example, go to the library, find the book, borrow the book, etc. The task of finding a book can then be divided into subtasks such as finding and open the library catalog, search the book in the catalog, and so on.

The figure shows how the tasks can be structured hierarchical according to HTA. The plan controls the order and conditions of the tasks. Tasks that can't be divided further are underlined (a line under the box). Subtask 4, Borrow a book, on the other hand, can be divided further, such as use the library card in the card reader, get the receipt, and so on.

As you probably noticed, it is possible to divide a task in almost extremely small pieces, but finally you reach a limit when there is not longer meaningful to divide it to subtasks. Where that limit is, depends on the case you are working with. In the library example, the lowest meaningful description of subtask is at the level 2.1 - 2.5, because for this design, it doesn't give much more to describe how each button is pressed. In other cases, when there are critical operations, in for example an air traffic control center, we have to analyze each button pressed in detail.

Real task are often very complex. A problem with HTA and task analysis in general, is that real problems become too big and complex to analyze and describe. Another problem is that the methods used (for example HTA) limit the sort of task that can be modeled. Tasks that overlap each other or are done in parallel are hard to describe, as well as interruptions in the task or unusual flows in the task.

Alan Cooper argues that the most important in interaction design is not the task, but the user's goals. Cooper believes that there is an important distinction between goal and task. A goal is a final state. A task, on the other hand, is a process in-between, which is required to achieve the goal. A focus on the tasks can result in a design that supports tasks that are not essential to the user or are not designed properly. A proper analysis of the users' goals, will lead to the essential tasks, which will give a better and more usable system, according to Cooper.

His method to achieve this is called goal-directed design. An important ingredient is also to describe the user as a persona (introduced in the previous part of this lesson). An overview of goal-directed design and personas can be found in a separate pdf-document: Persona - an overview. Some more information can be found at the net: Goal-directed design by Alan Cooper

The above provides a brief overview of the area. In order to complete the picture you should read the literature and visit the links listed below.

Required reading

• Benyon: Chap. 8, 9, 20, 24 (optional) (Dix chap: 6-6.5, 13.3)

Further reading

• Persona - an overview
• "Användarcentrerad systemdesign" of Gulliksen & Göransson (Swedish), chapter 9.1.

• Goal-directed design och Personas
  • Goal-directed design by Alan Cooper.
  • User Personas - A short introduction and examples of personas.
  • Perfecting your personas by Kim Goodwin
  • Bringing your personas to life in real life by Elan Freydenson.