Overview. From exercise 1, you will have a set of concrete and detailed examples of key tasks. In this exercise, you will
Step 1: Key users and tasks. Your prototype will be designed to support the customers and key tasks identified in Exercise 1. At this stage, you should have a description of the types of users of your system as well as a set of tasks. This information should have been validated by end users and / or their representatives (see Exercise 1). If they haven’t been validated, you must do this! If the identified user or selected tasks are the wrong ones, then the final system you develop will not support the real needs of your actual customers.
The user audience and task list may contain far more (or perhaps too little!) diversity than is appropriate for your system. In this step, your group should discuss which segment of customers and tasks should be supported. Similarly, your group should decide which of the tasks are essential and must be supported by the system (the key tasks that people must be able to do with the system), which are less essential but could be supported, and which are non-essential or best handled by other means (and which the system should not handle).
The outcome of this activity is a description of the expected customer, the grouping of tasks by the criteria above, as well as a statement on whether the task set described is considered complete, or whether they require further work.
Step 2. Developing low fidelity prototypes. Use the key users and tasks 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 (try a different method for each prototype!). You should also be thinking about what conceptual model the system will portray to its customers. You should not be concentrating on prettiness or completeness; rather, you are trying to show the overall representation and 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.
You should use the ideas of "psychology of everyday things" and "beyond screen design" to help you, as well as your general knowledge of other systems (there is nothing wrong with copying ideas, providing its legal!).
Hints: To get diversity, each of you may want to try to create a few rough sketches before gathering as a group. You may also want to talk to the systems people in your group, because there may be opportunities that already exist with the current way the information is stored and presented (e.g., with existing versions), or constraints that limit what you can do (e.g., Windows ’95). You should also realize that some people may be better at this than others; this is not supposed to be a competition!
Step 3. Evaluate the prototypes. Your next step is to evaluate the prototypes.
Step 4. Preliminary decision. At this point, you should have a reasonable idea of which prototype styles are worth pursuing. Make your decision. If you have more than one, you may want to continue developing both a bit further. If you have no worthy candidates, return to step 2.
Step 5. Refinement. Refine your prototype by considering the nuances of each task, the functions that must be incorporated, and the expected reaction of each user. You may want to start considering the more subtle aspects of interface design at this point (e.g., psychology of everyday things, principles of graphical screen design, design principles).
To bring to the next class. You will bring to the next class a refined version of your paper prototype.