Appendix 2: Developing and Evaluating Initial Prototypes

HCILectures.TCSDAndPrototypingDevelopingPrototypes History

Hide minor edits - Show changes to markup

March 29, 2007, at 09:47 AM by 85.241.170.239 -
Added lines 1-28:

(:title Appendix 2: Developing and Evaluating Initial Prototypes :)

Don't forget to read the class notes and accompanying papers on prototyping.

Step 1. Developing low fidelity prototypes.

Use the key users, tasks, and system requirements generated previously 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 several 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., if customers are already using software), or constraints that limit what you can do (e.g., if the system must be delivered as a Windows 95 application). You should also realize that some people may be better at this than others; this is not supposed to be a competition!

Step 2. Evaluate the prototypes. Your next step is to evaluate the prototypes.

  • Discuss each prototype to see whether it is a possibility in principle (e.g., are there obvious problems with the conceptual model? Is it implementable? )
  • Do a task-centered system walk through for each of your key tasks, and each of your user types. The prototype plus task will create the scenario. Details were discussed in class, by the Cheap Shop example, and in the reading supplied in Appendix 1.
  • From the ones that are left, elicit reactions and further discussion from customers / counter people / appraisers. You may find that your end-users will tell you about further tasks and task details which were not thought about before!

Step 3. Reconsider priorities, and make a preliminary decision.

Based on the prototype and evaluation exercise, you may wish to reconsider what customers you will address as well as what tasks and requirements you will support. It could be that you were wildly optimistic about what you could do!

At this point, you should have a reasonable idea of which prototype styles are worth pursuing, or whether you should start again. Make your decision on what direction(s) to follow. If you have more than one direction, you may want to continue developing both a bit further. If you have no worthy candidates, return to step 2.

Hint. Don't feel committed to any prototype. This is the time where prototypes are quick to generate and cheap to discard. Use this time to explore the design space. While you may want to just get on with it, a bad design choice now can have disastrous and expensive repercussions later.

Step 4. Refinement and evaluation (to be started in Assignment 3).

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). You should be continually evaluating these prototypes as appropriate. Real users should be commenting on them. You should be using walk-throughs, heuristic evaluation, and various observational methods.

If you follow this process, your prototypes will evolve from a competing series of design ideas, to a crude single design representation, to more realistic looking screen designs, to functioning systems. As your design is refined, you will move from very low fidelity prototypes done on paper to medium fidelity prototypes done on-line, likely through an interface builder. You will have detected and corrected the major interface design problems, and will be concentrating on fine-grained details. Eventually, you will create vertical prototypes with back-ends that fake some of the system functionality. To the user, however, it will look like the real system.