Constructing a prototype enables you to create the illusion of a completed application with a fraction of the time and energy. Team members can evaluate the resulting prototype, but more importantly, the prototype can be tested for usability with your target audience. Making changes to prototypes is faster and easier than changing applications that are to be shipped. There is less resistance among team members to changing prototypes, as in many cases the prototype will be discarded prior to working on the application itself.
A prototype is a working model of your final product. Prototypes come in two varieties, paper and online. Paper prototypes are made of paper, clear plastic (write-on transparencies), and cardboard; these models require human facilitation to function as "working" products. Online prototypes are software applications that run on computer desktops or, in latter stages, on the actual hardware, such as a Pocket PC. Online prototypes function without the need for direct human facilitation, but many of the prototype responses are predetermined; i.e., "canned."
Online prototypes are more prevalent, but I think paper prototypes should be used instead in most cases. While developers alone can work on online prototypes, paper prototypes can be built by anyone on the team--and they can be built together, in a group setting. Paper prototypes can be constructed more quickly and, more importantly, they can be modified more quickly, even between usability tests. Finally, there is no temptation to ship a paper prototype, while the temptation to ship an online prototype is so great that most of today's software was once a "working prototype."
Paper prototypes
The first step in creating a paper prototype is to select scenarios that will enable you to test the features of your user interface. Prior to building your paper prototype, it will be useful to produce a list of usability tasks. Since you do not need to model the entire user experience, you will model only the areas of the interface required to complete the tasks. The idea behind paper prototyping is to test the usability of your information architecture. In order to test the hardware, you will need to construct an online prototype.
Paper prototyping, being a "quick and dirty" solution, requires compromise. In order to produce in a few days a prototype of a system that will require months to build, you will need to leave some things out, such as most types of horizontal scrolling.
Each paper prototype will consist of a model of the Pocket PC and pages from the user interface. I refer to the hardware model as the "blinder," since it contains a cutout, behind which the pages will be placed. The pages can be as long as you need, since the blinder limits their visibility. Horizontal scrolling is tough to model with a paper prototype, but it can also be accommodated by increasing the size of the page upon which the device is drawn.
With paper prototypes, the pages that are displayed as a result of hyperlinks or menu selections often contain "greeked" text. When the actual text for a response is not known at prototype time, designers frequently scribble where the text would appear. As the usability moderator, you can interpret this "greeking" in an appropriate way for the respondent, or better yet, ask the respondent what the text might be. The respondent's expectations could drive the design (ergo the term "user-centered design"). If respondents are confident of what the text will be, their assumptions could easily become the basis for the text in your application.
Dynamic page generation
During usability testing of paper prototypes, each page is hand-assembled by team members who act as the "computer" after each button press or screen tap, since the myriad number of possible combinations usually cannot be prepared in advance. While the pages are being assembled, it is the moderator's responsibility to keep the respondents occupied and/or entertained. The respondents should not focus their attention on the act of rendering the pages, but should instead keep focused on the application, perhaps describing what they expect to appear.
Printer-friendly version
