Human Computer Interaction: CPSC 544
UBC Computer Science - Fall 2009

Overview:

In the first phase, you proposed an idea that forms the basis of a course project.

In this phase, you will perform a task analysis of your idea, generate some rough early sketches of your idea, and create and evaluate low-fidelity prototypes based on the task analysis.

Fundamentally, this means that you begin the design process 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. You 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 the user and their tasks. 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 iterative design.

In this assignment, you will begin your iterative design of your idea using task-centered system design methods.  The immediate purpose of this assignment is to give you experience at:

• articulating good task descriptions
• interviewing or otherwise consulting potential users with regards to their work
• using the task descriptions to decide upon system requirements
• brainstorming design alternatives for your system  based upon the above
• sketching out the rough ideas
• developing low fidelity prototypes
• evaluating the various prototypes through a task-centered walk-through
• evaluating a prototype informally with a small number of users
  

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

• a list describing 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
• early sketches of your design alternatives
• a low fidelity prototype
• a task-centered walkthrough of the prototype
• informal evaluation with a small number of users
  

Deliverable:

Your group will deliver a system design and discussion portfolio. The portfolio will include the following sections.

Section 1: Tasks and requirements  (5-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.  You should include:
   • Background including the current work situation and why your system is needed
   • 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 details the general expectations of 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 (eg, 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. Describe how the tasks were collected and validated.
3. Tentative list of requirements. From the task examples, and associated inquiry with potential 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.    

Section 2: Sketches of design alternatives  (no page limit)

1. Describe alternative design possibilities that your team has come up with based on the requirements generated in the previous section.

Section 3: The first prototype, task-centered walkthrough, informal user evaluation  (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 identifiied in the task analysis phase. Include the prototype(s) in your portfolio.
2. Team discussions, walkthrough, and informal user evaluation. Discuss the prototypes with your team and 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.
   

A note on the Portfolio. The portfolio is intended to document the progression of your design, beginning with this phase, and continuing through the next phases.  Your portfolio must be neat, well-organized, and visually appealing. Portfolios should be constructed out of a 1" or smaller 3-ring binder (the professor 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 your group name, the names of the group members, and the title of the project. The first page should be a table of contents, which will grow over time. You will add to this portfolio as you complete each phase of the project. You should include references to published material and pointers to online information if pertinent.

You should include your marked project proposal in your portfolio as well, so the reader understands the progression of your entire project.

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

Depending upon your situation, you may or may not be able to access your real users 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 user. 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 a representative of the user. When you cannot get in direct contact with end users, you can use representatives instead. These will be people who have the most knowledge of the users' needs. Examples are help desk people, a worker's manager, or a caregiver. However, it is crucial that the user representative has a deep and real (rather than idealized) understanding of what the users actually do. 
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 current or potential users later, to see if these tasks indeed reflect what they do!

Note that in addition to interviewing, you may wish to administer a questionnaire to users (or representatives), in order to reach a wider group of people.

For whatever approach you chose, do the following steps. If you have a user and/or representative, you will work with them. If you are "making it up", try to imagine as realistic a situation as possible.

1. Have the users/representatives/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 want to solve, what information they brought into the meeting, the steps taken in the actual process, the constraints they had (e.g., time) in performing the process, what was produced (i.e., some artifact of the process), 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 or activity your system is intended to support.
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.

Step 2. Validating the tasks. The next step is to get a reality check of your task list. Have end-users and/or 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 users!). 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 user representative or just yourselves 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 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. Brainstorm design alternatives. From the task examples and requirements, your team should roughly sketch out several competing interfaces. 

Step 5. Develop low fidelity prototypes. Discuss and choose the most promising of your interface sketches, and develop a horizontal low-fidelity prototype using storyboards or Pictive methodology (you can try a different method for each prototype!) that demonstrates how the interface fulfills the requirements. 

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 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 6. Task-centered walkthrough. Test the prototype(s) for usability bugs (problems, faults, weaknesses) by performing a task-centered walkthrough.

Step 7.  Evaluation with users.  Select the most promising of your prototypes and perform an informal evaluation with two (or more) real users. Test the prototype for usability bugs (problems, faults, weaknesses).

Appendix 1: How to Write Good Task Examples

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.:
    • where does information come from?
    • where does it go?
    • 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.

Example task description for a clerk in a video store, including discussion. The eventual system will assist the clerks to perform their tasks.

George Marlay, a regular video store customer, approaches Mary and asks if they have the Frankenstein comedy video. She asks if he means "Young Frankenstein" by Mel Brooks, and he say yes. She then directs him to the shelf where the video is expected to be. George retrieves the video card and brings it to the front desk. Mary asks for George's membership card, but George has forgotten it. Mary then looks up his membership number. Mary checks out the video, but reminds George that he has not yet returned the video "Brazil", which is now a day late. George says that he will bring it in later today, and leaves with the video.

Discussion. This task contains many typical clerk activities, which deals with vague requests about video titles, the location of the video in the store, forgotten membership cards, the video checkout activity, as well as reminders to customers about late videos. Most these tasks are frequently done, and important.

Mary Farness, an experienced full-time clerk at the video store, opens the store in the morning. She begins the day by checking in all the videos returned in the night video slot, which typically number between 90 to 150 videos <should have a list of these, including identifying text or other marks used to check these in>. She pauses her task whenever customers ask for her services. She usually checks in ten videos, and then re-shelves them before going onto the next ten.

Discussion. In this case, the "user" is the full time person who normally carries out this task. We expect them to be typical of an experienced clerk who will know the process well, and who will become well practiced at using the target system. The task is routine and frequently done.

Anil, a part time clerk who works the telephone, comes in for an hour every third evening. His job is to search the rental records to find customers who are at least one day late on their video returns. For example, he phones Bob Jakobs, who is two days late. Bob answers, and Anil identifies himself, tells him that he still has the video "Volcano", and reminds him to return the video. Bob says he will bring it back in an hour or so, and Anil crosses his name off the list. He then phones Ania Sliven, and says (more or less) the same thing. However, Ania says that she has already returned the video the day before. Anil puts her on hold, runs to check the shelf and finds the video there. He apologizes and hangs up. He then phones Ang Lee, but there is no answer. He makes a note that he should try this person again later. He continues in this manner. When he has finished the list, he starts again on those who have not answered.

Discussion. This task identifies a specific activity that is less frequently done but still quite important. It also indicates that a non-regular staff member may be doing this task.