& Class Notes
3724 - Human Computer Interaction - Summer 2005 -- Pardha S. Pyla
Scenarios, Screen Design, and Early Prototype
Due as per
In this project
assignment you start designing the user interaction for the user interface
of your target system. You start this by writing design scenarios and
designing the screens to go with them. You will use a rather complete
set of static screen pictures as an early low-fidelity prototype to do
a design walk-through with your team and your client, after which you
write a walk-through evaluation report.
What To Do
- Create (and develop by
iteration with screen sketches), a total of three usage/design scenarios,
representing six different key user tasks (selected in item 7 of Project
2) and including all of your user classes.
- Draw the screen designs
to go with the scenarios above.
- Annotate one of these
design scenarios with roles, objects, work context, etc., as we did
- Develop your scenarios
and screen designs by iterating them several times among your own
- Do a walk-through with
your client and some potential and representative users at the client's
site, using your screen designs as an early low-fidelity prototype.
How To Do
Using the detailed
techniques described in the class notes and discussed and practiced in
class, develop usage scenarios, screen designs, and a walk-through evaluation
- A scenario should follow
one thread through one task. The task is the right size for one of
these scenarios if it has about 6-10 steps, involves several user
interface objects (such as buttons, menus, and dialogue boxes) and
includes some navigation through your application. You should be able
to do a verbal "walk-through" of a scenario in under five minutes,
for someone who hasn't seen it . Scenarios begin as emerging stories
of usage instances. They evolve (through iteration with screen sketches)
into rich, detailed narrations that describe how tasks are performed
in terms of specific physical user actions on specific user interface
objects (e.g., "to launch the calendar system, Sue double-clicked
on the Calendar icon"). The goal of the scenarios is to reveal as
much as possible about user actions on user interface objects, thus
driving out detail in early design. That is why iterating scenarios
with screen designs is important.
- Neat hand-drawn screen
pictures are acceptable. Any simple drawing package, including Visual
Basic, is a good way to make it look good and save work while revising
for iteration. It certainly does not have to have a platform-specific
look and feel at this early stage. The screen layouts should include
notes and labels as needed to further explain objects and their behavior
and their use (e.g., "this button invokes the xyz function"). Draw
enough screen designs to support doing the tasks (related to your
scenarios) that you expect to cover in your walk-throughs with the
In the deliverables, you will combine steps 1 and 2 (i.e., you will
combine the scenarios with the screens). This illustrated descriptive
"story" should flow like a movie or a story-board for a
movie. Pictures of the screens are to be interspersed with the narrative
text of the scenarios. You don't need to number and caption each figure
and then refer to it by figure number. It is enough to just put the
figures in-line with the text. As the text describes something in
a screen, put the figure of the screen design next and then more text.
The text and screen should be closely related and the text should
refer to specific objects, etc. in the related screen picture. Make
the text and the screen picture correspond closely so that the screen
picture obviously illustrates what you are describing in the text.
If you need to refer to a screen picture again, later in the text
or in another scenario, you should repeat the figure rather than refer
back to a figure on a previous page.
- Pick just one interesting
scenario for annotation, using the labeling technique discussed and
illustrated in class. Do a simple scenario analysis, as we did it
in class, by underlining or highlighting interaction design elements
in your scenarios that indicate user roles, actions, objects, object
attributes, object relationships, and work context/environment. Please
also label (e.g., with a 'call-out' line to it) each of the highlighted
items with its interaction role (e.g., user type or role, task, subtask,
physical user action, cognitive user action, interface object such
as a button, object attributes, object relationships, work context/environment
descriptions). Do this with just the scenario text. Make sure your
screen designs done in the previous step support this scenario by
including the items you have underlined here.
- Iterate many times between
your scenarios and screen designs, using design walk-throughs with
your own team on each version. The more you evaluate and iterate at
this early stage, the better your design later.
- You definitely have to
meet your client (me) to do this walk-through of your scenarios and
screen designs. Your final set of screen designs should cover the
scenarios of item 1 above well enough to support a design walk-through
with your client. These are static pictures of whole screens, which
are good for walk-throughs when you are 'driving'. In contrast, your
later low-fidelity prototype will require separate moving parts for
early usability evaluation with the users 'driving'.
One person can be the "explainer" or you can take turns with that
role. The rest of the team should take notes about client and user
reactions, comments, and suggestions. The explainer sets up the task
to the client and narrates what happens as the user would perform
the scenario tasks referring to the screen pictures and pausing as
needed for questions and discussion by the client. The client doesn't
do the tasks yet.
binder, create a "tabbed" section labeled "Project 3". Add this section
to the front of your team binder. This way, your binder becomes
a cumulative record of your whole project, with the most recent parts
first. This section should start with its own separate cover page with
(mostly the same as on the front of the binder):
Contents of Project 3 section:
- "Project 3: Scenarios,
Screen Design, and Early Prototype"
- Team number
- Project name
- Name of client organization
- One-line description
- Team member names
- "CS 3724– <current
The main purpose
of this document is to describe how the system works, done in following
steps. Number and label your items per this list:
- Begin after the tab for
this section, with a blank printed grading
form for this deliverable.
- Then include a Table of
Contents for this particular deliverable (not the whole folder).
- Then follow with these
items, numbered as they are here:
- To make this report
a stand-alone document, repeat the latest version of your product
concept statement, as a synopsis of your project.
- Give your final version
(the most detailed version from your iteration) of each scenario,
naming each with a label/title. Please begin this item a restatement
of your user class definitions (just a sentence each, not the
whole matrix) to provide context for the scenarios.
- Combine this step
with step 1 above in your write-up (labeling it "1-2")
by interspersing figures (hand drawn or computer drawn) of appropriate
parts of your screen designs, whenever the first reference is
made to same in a scenario. The combination of scenario narrative
and sketches embedded in the text should flow as one integrated
description (rather than, say, putting all the figures at the
- The text of your
selected scenario, with various interaction design elements highlighted
and labeled by interaction role.
- Very briefly describe
your iteration process. Tell (honesty, now) how many iterations
you actually did as a team, before going with it to the client.
- a) Describe or show
how you used screen pictures as an early low-fidelity prototype,
describing the process you used with your client to do
the design walk-through
b) Write a description of the results of the walk-through:
how it went, what you learned, usability issues and questions
that arose, plans for design changes resulting. Do not, however,
make these design changes to the screen design that you hand in
(but do save them for a later part of the project).