Instructor: Sheelagh Carpendale
CPSC 481: Foundations of Human Computer Interaction
Fall 2002
Assignment #1
Assignment:
Task Centered Design and Prototyping
Handouts
Overview
This project is a hands-on exercise in 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, where 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 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 called iterative design.
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 methods. (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 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,
-
a low fidelity prototype, and
-
a task-centered walkthrough of the prototype.
Teams
You will work with at least two others from your lab section.
The idea of working with others is to get alternate design ideas, alternate
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.
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
Your group will deliver a system design and discussion portfolio
written to the imaginary vice-president of your company. The portfolio
will include the following sections.
Section 1: Tasks and requirements (~10 pages)
-
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. Subsections should include:
-
Background, 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 details the
general expectations of the system
-
System constraints that limit the design e.g.,
budget, equipment, operating system, legacy systems, etc.
-
Concrete task examples. You will list at least 5-7
concrete task examples that have 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 (eg frequently done and
important, infrequently done but still important, rare and not important,
etc), and whatever other nuances you feel should be included.
Note: include a paragraph or two that describes
how the tasks were collected and validated.
-
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 and requirements
in lab.
Section 2: The first prototype and walkthrough (an annotated
design + several pages)
-
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.
-
Team discussions and walkthrough. Discuss the prototypes
with your team and (ideally) 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 class
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 the group
members, the group number, and the title of the project. The first page
should be a table of contents, which will grow over time. This is followed
by your grading sheet and the sections.
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 and oral presentations, the completeness of the
work and the progressive development of the design.
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 time available for this exercise.
Consequently, each team should select the approach below that best fits
their constraints and team membership.
-
The ideal: Interviewing the client. 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.
-
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.
-
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 clients later, to see if these tasks indeed reflect
what they do!
For whatever approach you chose, do the following steps.
If you have a client and/or representative, you would do it with them.
If you are "making it up", try to imagine as realistic a situation as possible.
-
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.
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.
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 second reading (see attached).
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.
Note: This step is critical if you used a client
representative or just yourselves 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, up to those 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 horizontal 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
customer. You should be creating low fidelity prototypes e.g., paper sketches,
storyboards, or Pictive (you can try a different method for each prototype!).
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 (perhaps) 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.