Baecker, R., Grudin, J., Buxton, W., and Greenberg, S. (1996) Readings in Human Computer Interaction: Towards the Year 2000. Morgan-Kaufmann.
- Participatory design of a portable torque-feedback device, p.225-232. This paper is a case study of a participatory design, where chemists worked with computer scientists to develop technological scenarios for molecular modeling.
Handouts
- Nielsen, J. (1993) Extract-Chapter 4.8: Prototyping. In Usability Engineering, p93-101, Academic Press. Describes different styles of prototypes and how they can be used within scenarios.
- Rettig, M. (1994) Prototyping for tiny fingers. Communications of the ACM, 37(4), ACM Press.
- Muller, M.J. (1991) Pictive: An exploration in participatory design. In Proceedings of the ACM Conference on Human Factors in Computing Systems, p225-231, ACM Press.
- Rudd, J., Stern, K. and Isensee, S. (1996) Low vs. high fidelity prototyping debate. Interactions 3(1), p76-85, ACM Press.
Before beginning prototype design, you should have a set of concrete and detailed examples of key tasks as well as some idea of what users you want to support and what core requirements the system should be designed around. Use the key users and tasks as a type of requirements document to help you and your team (which will ideally include an end user) brainstorm several competing 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 (you can try a different method for each prototype!). You should not be concentrating on prettiness or completeness; rather, you are trying to show the overall 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 will discuss and choose the most promising of these designs, and develop a horizontal low-fidelity prototype (likely using the storyboard or Pictive methodologies) that demonstrates how the interface fulfills the requirements.
Hint: To get diversity, each group member may want to try to create a few rough sketches before gathering as a group. You should also realize that some people may be better at this than others; this is not supposed to be a competition!
Specifically, the next series of steps is to
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!
Your next step is to evaluate the prototypes.
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.
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.