Overview

The first step in an iterative user-centered system design is to get 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. This is a hands-on process which 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.

In this assignment, you will develop an interview or observation strategy for current or potential users. You will then interview and/or observe at least 3 potential users. From these, you will decide on the most important user goals, and develop corresponding personas for your project. You will also do a preliminary task analysis.

This is a group assignment, so you should work as a team.

Step 1: Determine the Project Management Structure

Meet with the members of the team and assign management roles to each team member. The manager is responsible for making sure the work gets done, not for actually doing the work themselves. Everyone needs to help out with the different parts of the project. Suggested management role breakdowns are:

• group manager (coordinate things; maintain the big picture)
• evaluation manager (coordinate evaluation of interface, including recruiting of potential users)
• documentation manager (coordinate writeups)
• design manager (coordinate design aspects of interface)

Some groups have three members, so in this case the group manager should also take on one of the additional roles. Your writeup should state who is taking on which roles.

Step 2: Design Interview Questions and Recruit Potential Users

Create an interview to assess what potential users would like to see in a design, and to form a basis for personas and tasks. If redesigning a system, also arrange to observe current users using the system you are redesigning.

Most useful would be a set of interviews with perspective users, but other means of discovering user needs and goals are also acceptable. Use the class discussions and the readings (Cooper, Nielsen, Gomol, Holtzblatt) to help guide you in this process. The Gomol reading is especially concise and helpful.

Depending upon your situation, you may or may not be able to access real potential users. Consequently, each team should select the approach below that best fits their constraints and team membership.

• The ideal: Interviewing potential users. 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.

• A reasonable alternative: Interviewing user proxies. If you cannot get in direct contact with end users, talk with an approximation to real users (for example, a manager's administrative assistant, if you can't reach the manager, or a graduate student in medicine if you can't talk to practicing physicians).

The following are recommended things to do during the interviews. Your needs may differ.

• Have the potential user or 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.

• On a more general and less detailed level, list as many related tasks and their variations as possible.

• 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.

Step 3: Conduct the Interviews

You should interview at least 3 people, but the more you can do the more representative your results will be. You should also find out if these people will be willing to talk with you later in order to assess your task descriptions, and eventually, your designs.

Be sure to record the interviews in some manner. If you use an audio or video tape recorder, you must be get the interviewee's permission to do so.

Step 4: Determine Personas, Goals and Tasks

Because it is unrealistic to meet all requirements and address all users, it is important to focus on a few representative types of users and goals. Based on these interviews, and your common-sense notions of what will be required for your project, create create personas, or hypothetical archetypical users, to capture the most important user types and their goals. Use the description in the Cooper readings to help you. Assign personal details to them in order to make them more vibrant and memorable.

Determine which tasks must be done, which are optional, and how often they will need to be done by each persona. Make a chart, table, or flow diagram to illustrate the frequency and/or importance of each of these tasks in isolation. You will use these together in the next assignment to create scenarios.

Remember that goals:

• Are what the user wants to do, but not how the user achieves them
• Do not to make any assumptions about the system interface
• Can be used to compare different interface design alternatives in a fair way
• Can be personal, practical, or false (don't focus on false goals!)

• Are very specific, although not necessarily accurate
• Are based in large part on the goals.
• Will be used to create scenarios (next assignment).

• Describe the steps necessary to achieve the goals
• Can vary with the available technology
• Are broken down into steps for task analysis, and are recombined into sequence of steps for scenario development (next assignment)

Step 5: Turn in the assignment

Each assignment for the class project is designed to be modular enough so that it can go nearly unchanged into the final report. Each group will have shared space in the class project directory; each assignment is expected to be written in HTML and placed in the project directory, (Kevin Heard is going to arrange for group directories once the group memberships are solidified. We'll send email with the directory locations once they are ready.)

Below, the number of pages refers to number of printed pages when printing from a web browser.

To turn in:

1. Team management structure (who is taking which role(s))
2. Revised Problem Statement, based on feedback from instructors (1 page maximum)
3. Explanation of how you developed the personas and goals. This can include results of interviews or other methods used to assess user needs and goals. (1 page maximum, not counting raw data such as interviews, which should be included as an appendix)
4. Description of personas and goals, along with justifications for these choices. Explain why you choose the number of personas that you did. (3 pages maximum)
5. Description of necessary and optional tasks, and their predicted frequency/importance for each personal, usually in the form of a table or chart (2 pages maximum).
6. Description of which team members did which part(s) of the work. (If everyone helped with each part, estimate the percentage amount done by that person on that part of the work. It should add up to 100% for each part.)
7. Appendices, if applicable

Upcoming due dates:

• Tues Feb 14: Personas, Goals, and Task Analysis
• Tues Feb 21: Scenarios, Comparative Analysis, and Preliminary Design