Project 3: Scenarios, Screen Design, and Early Prototype

Due as per class calendar.

Overview

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 in class.
Develop your scenarios and screen designs by iterating them several times among your own team members.
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 It

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

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

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.

Deliverables

Inside the 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):

"Project 3: Scenarios, Screen Design, and Early Prototype"
Team number
Project name
Name of client organization
One-line description of project
Team member names
"CS 3724– <current semester, year>"

Contents of Project 3 section:

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:
1. To make this report a stand-alone document, repeat the latest version of your product concept statement, as a synopsis of your project.
2. 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.
3. 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 end).
4. The text of your selected scenario, with various interaction design elements highlighted and labeled by interaction role.
5. 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.
6. 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).

Grading

This design document specifies the content and style of the interface. At this point the quality of your design is considered but not stressed in grading; it is more about how well the document describes it. Your design should be fairly detailed.