Assignment:
Task Centered Design and Prototyping

Handouts

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, because 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 it's only normal for your initial designs will be crude and riddled with usability problems, you will have to identify potential problems by continually evaluating your design and by crafting new designs. This is called iterative design (recall the design-implementation-evaluation cycle).

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 techniques. (You may be continuing this design in assignment 3). The immediate purpose of this assignment is to give you experience at:

• articulating good task descriptions
• using the task descriptions to decide upon system requirements,
• brainstorming low fidelity prototypes based upon the above, and
• evaluating the various prototypes through a task-centered walk-through.

The outcome of the assignment on Task-Centered System Design is a design portfolio containing:

• a list describing the 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.

Teams

You will work with two others from your lab section. The idea of working with others is to get alternate design ideas, multiple 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.  Because you will be presenting parts of your assignment during lab time all group members must be registered in the same lab.

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 (Due when you hand in your portfolio for Assignment 1)

Your group will deliver a system design and discussion portfolio written to the imaginary Vice President of Usability of your company.  The portfolio will include the following sections.

Section 1: Tasks and requirements (~15 - 20 pages plus Appendices.  For this course it's quality and not quantity that counts!)

1. Introduction. Introduce and describe in general terms the background to the system. You should briefly describe the expected users, their work contexts, and what they will use the envisaged system for.  Subsections should include:
   • Background environment, including the current work situation and why a computer system is coming in
   • Expected types of users of the system, including their experience, expected training, etc.,
   • Work contexts that describes the work setting and typical situations of the users
   • What the system will be used for as well as the general expectations towards the system
   • System constraints that limit the design e.g., budget, equipment, operating system, legacy systems, etc.
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 (e.g., a typical customer), the relative importance of the task (e.g., frequently done and important, infrequently done but still important, rare and not important, etc), and whatever other nuances you feel should be included. 
   You should include a paragraph or two that describes how the tasks were collected and validated.  If you took extraordinary measures to acquire and refine this information it may make a difference to your assignment grade so don't forget to mention it all!
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 (~1 - 2) and requirements in lab (listed in the schedule as presenting steps 1 - 3 of assignment 1 in lab).

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

4. 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.  You should not only include your final design but it is also a good idea to show the early ideas that your group generated but may have discarded.  This will help to illustrate to your marker how your group went through an iterative design process as you all created the prototypes (remember: design-implementation-evaluation).
5. Team discussions and walkthrough. Discuss the prototypes among your group members and ideally with 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 lab (listed in the schedule as presenting steps 4 & 5 of assignment 1 in lab).

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 all the group members and the title of the project. The first page should be a table of contents which is followed by your grading sheet and the content of the respective sections.

A note on the grading. Grading will be based upon the sophistication and maturity of the work, the logic of the written and oral presentations, and the completeness of the work.  Although it would be nice to have truly elegant designs at this stage we are focusing more how well you completely and objectively evaluate your designs.  More than likely you will make major redesign changes when you return to your project for Assignment 3.

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 amount of time available before lab 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.
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 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 lab 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 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 lecture.

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.

Reminder: This step is especially critical if you used a client representative (alternative ii) or just your group members (alternative iii) 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, as well as those that 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 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 user. You should be creating low fidelity prototypes e.g., paper sketches, storyboards, or Pictive (you can try a different method for each prototype if you are really keen!). 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  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.