Appendix 2: Generating a list of expected users, and an initial list of tasks 

The main idea is to 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 (see Appendix 1).

Depending upon your situation, you may or may not be able to access your real clients in the short amount of time available before tutorial presentations. 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 manual 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 actual users 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: even if one or more of your group members are members of the user group make sure that you interview users that are not a part of your group.  It's simply too easy for someone who actually has to complete the implementation to become too biased to give an honest appraisal of how usable that the system may or may not be.
2. A reasonable alternative: Interviewing the client representative. When you cannot get in direct contact with end users, you can use customer representatives instead. Except for the actual client, these people will 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 (e.g., restaurant manager also waits on tables from time to time).
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 will at least provide a concrete description of who your are developing for and what they plan to do . Note:  If you don't have enough time to get in touch with actual users in time for your tutorial presentation make sure that you get in touch with actual users as soon as possible.  (It should definitely occur before you hand in your first assignment!)

For whatever approach you chose to employ, make sure that you complete the following steps. If you have a client and/or representative, you would complete these steps 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 so make sure that you are thorough in your investigation.  Alternatively, the task could be derived from direct observation of users doing their work.  Ideally they should be based on a combination of both approaches.
2. On a more general and a less detailed level, list as many related tasks and their variations as possible.
3. There will be many task variations in the list. Identify (with the user, if possible) which tasks are frequent, which are infrequent but still important, and which are rarer and not very important.

At this point, you will have 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 Appendix 1 and the lecture.