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 that I talked about in class.

In this assignment, you will begin your iterative design of a particular system (see Appendix 4 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 the course instructor (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 new 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 (~20 - 30 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.

• Background environment, including the current work situation and why a computer system is coming in.
• System constraints that limit the design e.g., budget, equipment, operating system, legacy systems, etc.

Section 1: Identification and requirements

Step 1: Identification

• 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.
• 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!  For tips on generating a list of expected users and tasks see Appendix 2.  As you generate different versions of tasks (because you are refining them) be sure to include the older versions in an appendix.  This will help to illustrate to your marker how your group went through an iterative process as you worked your way towards producing the final version of your 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 (e.g., the user's boss) or if your group made up imaginary users instead of contacting 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: Tentative list of requirements. 

• From the task examples (and possibly consulting with users), 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.   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.

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

Step 3: Prototyping (Storyboard or Pictive). Develop several low-fidelity prototypes of designs that you believe will satisfy the major requirements.   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 3).  Again be sure to include all versions of the prototypes in your portfolio even your earliest designs.  This will help to illustrate to your marker how your group went through an iterative design process as you all created the prototype.¹  Write a brief (no more than a few sentences) description for each prototype - how did this version improve over the previous one,  why did you eventually abandon the approach taken in this version in favor the one taken in the next version or for the latest version that you have completed what are some future improvements that could be made. 

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: 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 latest prototype designs that seem promising, convert each of your tasks from Section 1 to scenarios to perform a walkthrough evaluation of your prototype for each task that you wrote up in Step 1 (except for the 'rare but unimportant tasks').  For each walk through describe the problems that you saw in the system during the evaluation:

The walk through of the Cheap Shop system with Task #3 indicates that the system does not allow for the easy entry of multiple order items.  Nor does there appear to be any way to edit an existing order...

Then try to synthesize and summarize the results of each walk through and describe what are the major areas of improvement for the system as well as what seemed to work for the system as a whole.

One of the major problems with the Cheap Shop System is the way in which data entry has been implemented: requests for data that is irrelevant to the transaction (e.g., credit card number for cash transactions), vague or no indications of the format of the data (e.g., phone number)...

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.

Presentations in tutorial

Section 1: Steps 1 & 2

You will be asked to present sample tasks (one or at most two) and requirements in tutorial as well as providing some additional background information to set the stage for your project.  It is up to your group as to how you wish to present things (e.g., by using electronic or transparent slides, giving out paper handouts that contain the tasks - although writing the tasks out by hand during the tutorial will probably take too long so you should have something  prepared for your presentation). 

Section 2: Steps 3 & 4

You will be asked to show a prototype and discuss the walk through results in tutorial.  Don't be afraid to be brutally honest in your critique!  The idea isn't to develop great prototypes at this stage but to learn how brainstorm ideas, evaluate the ideas and to make improvements in the next version.    Again which prototyping technique that you use is up to you (e.g., Pictive 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.

^{1 Also including previous versions of work may be useful if any problems arise over the division of labor for your group. Older versions can be used as 'evidence' that a particular group member contributed to the overall effort.}