Appendix 1.
Getting to Know Users and Their Tasks

Step 1. Getting started and the outcome

Read the following papers, reprinted in the book:

Baecker, R., Grudin, J., Buxton, W., and Greenberg, S. (1996) Readings in Human Computer Interaction: Towards the Year 2000. Morgan-Kaufmann.

• Chapter 2: Design and Evaluation and How to Design Usable Systems, as both deal with elements of user involvement during design.
• Gould, J. (1988) How to design usable systems. is an old but still excellent introduction to the notion of user centered system design.
• Lewis, C. and Rieman, J. (1993) Chapter 2: Getting to know users and their tasks is the source for the exercise and for the following notes.
• Chapter 3: Considering Work Contexts in Design, p.187-195, This chapter introduction talks about work contexts. Since much of this involves understanding users and how we can involve them in the design process, it is relevant background for this topic.

The outcome of this exercise on task-centered system design is:

• a list describing expected users of the system and their work contexts,
• a list of actual, representative tasks that people are expected to do,
• a prioritized list of system requirements,
• a low fidelity prototype, and
• a task-centered walkthrough of the prototype.

The best design team would have people from diverse backgrounds, which will give the team different perspectives on the problem. For example, a team could comprise a project manager, a marketing person, a programmer, a representative end user, and/or a help desk person who regularly deals with end users.

Step 2. Generating a list of expected users and an initial list of tasks.

In this step, you interview knowledgeable people about their real-world tasks and observe them doing their tasks. Your goal is to generate an initial list of concrete task descriptions.

Depending upon your situation, you may or may not be able to access your real clients in the short time available for this exercise. Consequently, each team should select the approach below that best fits their constraints and team membership.

1. The ideal: Interviewing the client. Get in touch with current or potential users. These users may now be using paper methods, competing systems, or antiquated systems for doing their tasks. Interview them about why and how they do their work activities, and what they expect out of a system. Ideally, this interview will occur while you are observing them do their work activities. These interviews and observations will give you some contact with customers and give you a feel for the real situation. This is more important than you think, for it will make you realize that ‘the user’ is not an abstract notion, but real people with real needs and concerns. It will help you put a face on the faceless, and will help you understand where they are coming from. (Note: There is a method called Contextual Design that details this activity. It is probably too complex to do for this project, but you should be aware of it).
2. A reasonable alternative: Interviewing the client representative. When you cannot get in direct contact with end users, you can use customer representatives instead. These will be people who have the most knowledge of the clients' needs. Examples are help desk people, or a worker's manager. However, it is crucial that the client representative has a deep and real (rather than idealized) understanding of what the workers actually do. People who work "in the trenches" with the staff are the best bet.
3. When all else fails: Making your beliefs of the task space explicit. If you cannot get in touch with either real end users or representatives, use your team members to articulate expected tasks. While this runs the risk of producing tasks that bear no relation to reality, at least you will get a diverse list of tasks out (because you have a diverse team), and it will put your beliefs and assumptions on the table. You can always show these to clients later, to see if these tasks indeed reflect what they do!

For whatever approach you chose, do the following steps. If you have a client and/or representative, you would do it with them. If you are "making it up", try to imagine as realistic a situation as possible.

1. Have the client/representative/team recount a few (3-4) stories that typify the actual use of their system and/or process. Where possible, describe the people, the particular problems they wanted to solve, what information they brought into the meeting, the steps taken in the actual process, the constraints they had (e.g., time), what was produced, and whether they were satisfied with the outcome. All details are relevant. Alternatively, the task could be derived from direct observation of them doing their work.
2. On a more general and less detailed level, list as many related tasks and their variations as possible.
3. There will be many task variations in the list. Identify which tasks are frequent, which are infrequent but still important, and which are rarer and not very important.

Good task examples comprise a set of concrete, detailed examples of tasks that people now perform, or would want to perform on your system. Each task description should have the attributes described in the second reading and summarized below:

• Says what the user wants to do but does not say how the user would do it
  • you are not to make any assumptions about the system interface
  • we will eventually use this to compare different interface design alternatives in a fair way
• Are very specific
  • says exactly what the user wants to do
  • we will eventually use this to specify the actual information the user would want to input to a system, and what information they will want out of it
• Describes a complete job
  • should list all aspects of the task, from beginning to end
  • this forces designer to consider how interface features will work together
  • we will eventually use this to contrast how information input and output is carried through the dialog, ie:
    • where does information come from?
    • where does it go?
    • what has to happen next?
• Says who the users are
  • use particular people, if possible
  • reflects real interests of real users
  • the success of a design is strongly influenced by what users know and their real work context; we will eventually use this information to see if people realistically have the desire, knowledge and/or capabilities to accomplish their task with the system.

Some example task descriptions concerning a clerk in a video store, including discussion. The eventual system will assist the clerks to perform their tasks in their store.

Mary Farness, an experienced full-time clerk at the video store, opens the store in the morning. She begins the day by checking in all the videos returned in the night video slot, which typically number between 90 to 150 videos. She pauses her task whenever customers ask for her services. She usually checks in ten videos, and then reshelves them before going onto the next ten.

Discussion. In this case, the "user" is the full time person who normally carries out this task. We expect them to be typical of an experienced clerk who will know the process well, and who will become well practised at using the target system. The task is routine and frequently done.

George Marlay, a regular video store customer, approaches Mary and asks if they have the Frankenstein comedy video. She asks if he mean "Young Frankenstein" by Mel Brooks, and he say yes. She then directs him to the shelf where the video is expected to be. George retrieves the video card and brings it to the front desk. Mary asks for George's membership card, but George has forgotten it. Mary then looks up his membership number. Mary checks out the video, but reminds George that he has not yet returned the video "Brazil", which is now a day late. George says that he will bring it in later today, and leaves with the video.

Discussion. This task contains many typical clerk activities, which deals with vague requests about video titles, the location of the video in the store, forgotten membership cards, the video checkout activity, as well as reminders to customers about late videos. Most these tasks are frequently done, and important.

Anil, a part time clerk who works the telephone, comes in for an hour every third evening. He searches the rental records to find customers who are at least one day late on their video returns. He phones each customer on the list. If the customer answers, or if he reaches an answering machine, he reminds them to return the video and crosses their name off the list. When he has finished the list, he starts again on those who have not answered.

Discussion. This task identifies a specific activity that is less frequently done but still quite important. It also indicates that a non-regular staff member may be doing this task.

Why these are good examples:

• They say what the person wants to do, but does not say how it will be done. For later exercises, we can use these examples to see if a particular system would allow the person to accomplish their task.
• They are specific.They say exactly what type of information a person is bringing in to the task, exactly what information the person wants out of it, and how the person will use it.
• They describe a complete job. When we test a system, we can actually follow this sequence of events and see the amount of work that has to be done to get from one step to the next.
• They say who the user is. In this case, they identify particular people, their experience, and what knowledge/experience they have in their head. Again, this has implications to eventual use of a system.

Step 3. Validating the tasks.

The next step is to get a reality check of your task list. Have end-users and/or client representatives review your tasks. They should check to see if the set of people are representative of potential end-users of your product, if tasks capture the variations of those done by real people, and if details are realistic (they will be, if they are based on real customers!). You should ask for details that were left out of the original task description, get corrections, clarifications, and suggestions, and then re-write the task descriptions.

Note: This step is critical if you used a client representative or just yourselves instead of a real client. While it may not be possible for you to interview and observe many real clients, you can probably get one to comment on a compiled list of prototypical tasks.

Step 4. Deciding upon key users and a tentative list of requirements.

At this stage, you should have a description of the types of users of your system as well as a set of tasks. This information should have been validated by end users and / or their representatives. If they haven’t been validated, you must do this! If the identified user or selected tasks are the wrong ones, then the final system you develop will not support the real needs of your actual customers.

The task examples (and possibly by further discussion with end users) will provide clues on specific system requirements that you could use to design your system as well as who your target customers will be. Because it is unrealistic to meet all requirements and address all customers, it is your job to prioritize them. In this step, your group will decide which segment of customers and tasks should be supported and which will be excluded. Similarly, your group should decide which of the system requirements are essential and must be supported by the system (the key tasks that people must be able to do with the system), which are less essential but could be supported, and which are non-essential or best handled by other means (and which the system should not handle).

The outcome of this activity is a description of the expected customer, the grouping of tasks by the criteria above, as well as a statement on whether the task set described is considered complete, or whether they require further work.