Lecture Topics in HCI, by Saul Greenberg
Contents for: All Topics CPSC 481 SENG 609.05 Industrial Course

Assignment:
Task Centered Design and Prototyping

Handouts

  • Grading Sheet
  • Appendix 1: Getting to know users and their tasks
  • Appendix 2: Developing and evaluating initial prototypes
  • Appendix 3: Design ideas
  • Example: Steps 1-3 of your task (as shown in lab)
  • Example: Steps 4-5 of your task (as shown in lab)
    •

    Overview

    This project is a hands-on exercise on task-centered design and prototyping, which is the first step in an iterative user-centered system design. Fundamentally, this means that you begin your design by getting to know the intended users, their tasks, and the working context of their actions. Only then do you consider what the actual system design should look like, where you would base the design on real people, real tasks, and real needs. User centered system design is not an academic process where some cookbook formula can be applied. Nor is it an intuitive process where a programmer can sit in their office and think they know what the user and their tasks are. Rather, it is a hands-on process that requires you to go out and identify actual users, talk to them about what tasks they are trying to do, and understand the entire context of their work. You then base your designs on this information. Because your initial designs will be crude and problem-prone, you will have to identify potential usability problems by continually evaluating your design and by crafting new designs. This is called iterative design.

    In this assignment, you will begin your iterative design of a particular system (see Appendix 3 for design ideas) using task-centered system design methods and low fidelity prototyping methods. (You may be continuing this design in assignment 3). The immediate purpose of this assignment is to give you experience at:

    The outcome of this assignment on task-centered system design is a design portfolio containing:

    Teams

    You will work with at least two others from your lab section. The idea of working with others is to get alternate design ideas, alternate ways of looking at things, and more breadth at eliciting and interpreting evaluations. It is your responsibility to find team members that you can work with.

    Note that if this were being done "for real", the best team would have people from diverse backgrounds, which will give the team different perspectives on the problem. For example, a real 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.

    Deliverables

    Your group will deliver a system design and discussion portfolio written to the imaginary vice-president of your company. The portfolio will include the following sections.

    Section 1: Tasks and requirements (~10 pages)

    1. Introduction. Introduce and describe in general terms the background to the system. You should describe (in general) the expected users, their work contexts, and what they will use the envisaged system for.  Subsections should include:
    2. Concrete task examples. You will list at least 5-7 concrete task examples that has the properties listed in Appendix 1. Try to keep task descriptions short and to the point. Each task should be accompanied by a paragraph that describes the class of the expected user (eg, a typical customer), the relative importance of the task (eg frequently done and important, infrequently done but still important, rare and not important, etc), and whatever other nuances you feel should be included. 
      Note: include a paragraph or two that describes how the tasks were collected and validated.
    3. Tentative list of requirements. From the task examples, extract the major system requirements and prioritize them into a) absolutely must include; b) should include; c) could include; and d) exclude. Each category should be accompanied by a discussion as to why items were placed in that category.

      You will be asked to present sample tasks and requirements in lab.

    Section 2: The first prototype and walkthrough (an annotated design + several pages)

    1. Prototype (storyboard or Pictive). Develop several low-fidelity prototypes of designs that you believe will satisfy the major requirements. 
      You will include the prototype(s) in your portfolio.
    2. Team discussions and walkthrough. Discuss the prototypes with your team and (ideally) potential users. You should be concerned here with how the general interface representation fits the users' view of their tasks. For the prototype designs that seem promising, use the tasks from Section 1 to perform a task-centered walkthrough of your prototype. 
      In your portfolio, list in point form the problems and successes for each task. In essay form, summarize the major design problems that must be corrected, as well as what seems to work well.

      You will be asked to show these prototypes and discuss the walk through results in class

    A note on the Portfolio. The portfolio is intended to document the progression of your design, which includes your final project. Your portfolio must be neat, well-organized, and visually appealing. Portfolios should be constructed out of a 1" or smaller 3-ring binder (your TA will not appreciate having to carry around larger binders). Your portfolio should also use titled section separators (the index kind) to separate the major sections. The cover of the portfolio should include the names of the group members, the group number, and the title of the project. The first page should be a table of contents, which will grow over time. This is followed by your grading sheet and the sections.

    A note on the grading. Grading will be based upon the sophistication and maturity of the work, the elegance of the designs, the logic of the written and oral presentations, and the completeness of the work.

    Method

    Step 1. 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 (see Appendix 1).

    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.
    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 (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).

    Step 2. 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 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; c) could include; and d) exclude. Similarly, decide upon what kind of users you must address, up to those you will exclude.

    Step 4. Develop low fidelity prototypes. From the task examples and requirements, your team should sketch out several competing interfaces. Discuss and choose the most promising of these, and develop a horizontal low-fidelity prototype (using storyboards or Pictive methodology) that demonstrates how the interface fulfills the requirements. See Appendix 2.

    Specifically, use the key users, their tasks, and the prioritized requirements as a type of requirements document to help you brainstorm prototypes that illustrate how your system would appear to the customer. You should be creating low fidelity prototypes e.g., paper sketches, storyboards, or Pictive (you can try a different method for each prototype!). You should not be concentrating on prettiness or completeness; rather, you are trying to show the overall interaction style of your system. Each prototype should contain the core screens that illustrate how the system will work as a whole, including (perhaps) a sample interaction based upon some of the key tasks.

    Hint: To get diversity, each group member may want to try to create a few rough sketches before gathering as a group. You should also realize that some people may be better at this than others; this is not supposed to be a competition!

    Step 5. Task-centered walkthrough. Test the prototype for usability bugs (problems, faults, weaknesses) by performing a task-centered walkthrough.