Assignment:
Task Centered Design and Prototyping

Handouts

An additional resource: A description of the task-centered process and how each part of that process may look in your portfolio.

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 project ideas) using Task-Centered System Design methods and low fidelity prototyping techniques.  Reminder: You are welcome to pick a project other than the ones listed but you must first clear it with me.  Choose carefully because this will be the project that you implement in the third assignment.  (You can change projects between the first and third assignments but you will need to do a bit of extra work to investigate the background for the project).  The immediate purpose of  Assignment 1 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 task descriptions.
• 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.
• A task-centered walkthrough of the prototype.

Teams

You will work with two others from your tutorial 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 tutorial time all group members must be registered in the same tutorial.

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 (~15 - 20 pages plus Appendices.  This is only an approximate figure, for this course it's quality and not quantity that counts!).  The portfolio will include the following sections.

Section 1: Identification and requirements

• Background environment, including the current work situation and why a computer system is coming in
• 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.

1. Step 1 of the task-centered process: Identification
   1. Expected types of users of the system, including their experience, expected training, etc.,  
   2. Work contexts that describes the work setting and typical situations of the users.
   3. 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.   Be sure to 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 anything that may be relevant!
2. Step 2 of the task-centered process: Tentative list of requirements. 
   1. 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 tutorial as well as providing some additional information to set the stage for your project.  It is up to you group as to how you wish to present things (e.g., using the overhead projector - although writing the tasks out by hand will probably take too long so you should have some prepared for your presentation). 

Section 2: The first prototype and walkthrough (an annotated design + several pages for each walk-through evaluation)

3. Step 3 of the task-centered process: Prototyping (storyboard or Pictive). Develop several low-fidelity prototypes of designs that you believe will satisfy the major requirements. 
   You will include the prototypes 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 the cyclical nature of the design-implementation-evaluation cycle).
4. Step 4 of the task-centered process: 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, convert the tasks from Section 1 to scenarios to perform a walkthrough evaluation 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 for the system as a whole.
   
   You will be asked to show a prototype and discuss the walk through results in tutorial.  Again which prototyping technique that you use is up to you (e.g., Picitve with sticky notes, Pictive with transparencies, a card board storyboard), just make sure that the prototype is complete and clear/neat enough to let everyone understand how your interface is supposed to work.

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 outside cover of the portfolio should include the names of all the group members and the title of the project.  Inside the first page of binder list all names of group members along with each person's respective email address.  The second 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 1A. 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 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.
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 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 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.

Step 1B. 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 people!). 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 user. While it may not be possible for you to interview and observe many real users, you can probably get one to comment on a compiled list of prototypical tasks.

Step 2. 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 3. 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 4. Task-centered walkthrough.  

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