(10%) User needs: Tasks, scenarios, and references (~1,000 - 2,000 words)

This phase of the project lets you talk to representative users to understand their actual needs, and to describe tasks and a prioritized list of requirements.
  1. Follow the procedure described in the Appendix below. Write a report that describes each of the three steps.
  2. Provide annotated references (1-3 sentences for each) to a set of the key 8-12 academic papers, industrial reports, and web pages on your topic. Compare your work to existing products. I expect you to become very familiar with the topic you choose, to know about commercial products and academic research work in refereed conferences and journals. Look at www.acm.org/dl (free access from UMD IP addresses) and www.hcibib.org for published papers.


  • Page Length estimate is just to set a rough expectation of how long this would be if printed. Grading is not based on length.
  • NEW: Please describe who you talked in general terms (i.e., undergraduate female, restaurant owner, etc.) or how you generated the tasks. Do NOT include any personally identifying information about individuals you talked.
  • If you haven't already, change the link at Term Project to point to an overall project page that has one link for each phase of the project. I.e., when you turn this project in, there should be two links (one for the proposal, and one for the User Needs analysis).

Appendix: Methods for task analysis

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

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. 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.
  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 workers , 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 (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 and the second reading (see attached). [updated 2/25: BBB]

Step 2. Validating the tasks.

The next step is to get a reality check of your task list. Have a NEW set of end-users and/or client representatives review your tasks. They should check to see if the tasks capture the variations that they themselves would expect. 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 3. Deciding upon key users and a tentative list of requirements.

The task examples will provide clues on specific system requirements that you could use to design your system as well as who your target users will be. Because it is unrealistic to meet all requirements and address all users, it is your job to prioritize them. From the task examples (and possibly by further discussion with end-users), decide upon the major system requirements and prioritize them into a) absolutely must include; b) should include; and c) could include. Similarly, decide upon what kind of users you must address, up to those you will exclude.
Good task examples:
  • 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, i.e.:
      1. where does information come from?
      2. where does it go?
      3. 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