CS3724, Fall 2000

Due as per class calendar

Activities

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. See Deliverables below for details (e.g., how many scenarios to report).

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 and Screen Design"
• Team number
• Project name
• Name of client organization
• One-line description of project
• Team member names
• "CS3724 – Fall 2000"

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:

1. To make this report a stand-alone document, repeat your synopsis or a revised version thereof.
2. Create (and develop by iteration with screen sketches), a total of 6 usage/design scenarios, representing two different key user tasks for each of 3 user classes. 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. Although scenarios begin as somewhat general stories of usage, they evolve (through iteration with screen sketches) into 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 detail 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. It is these more detailed scenarios, connected to the physical details of the screen sketches, that are appropriate for this project deliverable. Therefore, the scenarios you submit here should be the final ones, the product of iterating the scenarios and screen designs.
3. For each scenario, write out your detailed scenario, including references to physical actions and specific user interface objects, interspersing figures (hand drawn or computer drawn) of appropriate parts of your screen designs, whenever reference is made to same. The screen layouts should include notes and labels as needed to further explain objects and their behavior and their use (e.g., "this button calls up the xyz function"). 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. For each scenario, do a simple scenario analysis by underlining parts of your scenarios that indicate user roles, actions, objects, object attributes, object relationships, and work context/environment. Do this with just the scenario text. Make sure your screen designs done in the previous step support your scenarios by including the items you have underlined here.
5. Do a of walk-through of your scenarios and screen designs for the client and some users at the client's location. 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 screens and pausing as needed for questions and discussion by the client.
6. Write a description of the process you used with your client to do the design walk-through (but not results yet).
7. Write a description of the results of the walk-through: what you learned, design changes resulting. Do not, however, make these design changes to the screen design that you hand in.
8. Write a list of these usability issues and questions that arose in this part of the project. For example, the team will not have a way to decide which approach to take on some design question, which way to represent something on the screen, etc. You should keep a list of such questions to address in your later evaluation.
9. You should also include a statement of your overall usability goals (from Project 2), linked to your user class definition(s), and show how they are addressed in terms of the principles and guidelines your team selected as important for your design and how they played a part in the design. Example:

1. Novice user, easy to learn with minimum training
2. Maximum retention over time
3. Minimum reliance on user memory

1. Accommodate broad range of user competence (briefly tell how)
2. Use of consistency (give example)
3. Use menus to reduce errors and memory recall

This design document specifies the content and style of the interface. The quality of your design is included in grading as well as how well the document describes it. Your design should be fairly detailed. Thought should have been given to what the guidelines say about wordings, prompts, button positions and labels, menu design, use of navigation, etc.