Database Reference
In-Depth Information
Figure 15.1: A very rough paper prototype screen that was used in usability testing.
On the other hand, using paper prototypes encourages them to work with you to evolve the design, not
just nod their heads in acceptance. The rougher the prototype, the better (to a point) because it readily
conveys the idea that the design is open to input versus it's already been designed and is now cast in
concrete with you merely getting their approval to proceed.
PowerPoint Presentations
Another technique we used a lot was to use paper screens printed off from PowerPoint slides. The
slides included screen captures of existing product panels, screen captures where we did some cut-
and-paste to make suggested changes, pencil sketches that were scanned in, and simple blocks with
arrows for navigation and blobs where stuff goes. Again, the three main notions were being "open for
input," "fast to produce and change," and "portable."
We've used a lot of PowerPoint prototypes in the past several years to communicate quickly and easily
among team members and customers in remote locations because it's easy to distribute the prototypes
online and then have everyone on a teleconference discussing them. At that point, the prototype really
isn't "paper" anymore, but more in a class that we started terming "mid-fi" a number of years ago.
Mid-Fi Prototypes
At that point, I was part of a small multidisciplinary team that was working on one of the first Web
applications. The product, BookManager BookServer, was an online document system. At that time,
the notion of Web applications was pretty new, and we wanted to get the concepts of the system
across to folks in as interactive a way as we could, as quickly as we could. We got bogged down trying
to use low-fidelity or paper prototypes because they were not really interactive enough to show the
power of our search engine, but we didn't want to spend the time to code high-fidelity prototypes, so the
notion of medium-fidelity, or "mid-fi," prototypes using HTML was born. Our team, which included a
programmer and an online help writer, could very rapidly mock things up for our customers, and even
make changes on the fly. This project is described further in a paper I co-authored called "Web-Based
Prototyping for User Sessions: Medium-Fidelity Prototyping" ( Leone, Gillihan, & Rauch, 2000 ).
Summary
What all these methods have in common was that they allowed us to refine our understanding of users
and what they needed. Storyboards captured our own preliminary ideas (and lots of questions) about
how the interface needed to work, paper prototypes encouraged dialog with users, and mid-fi
prototypes were useful for those questions that paper couldn't answer.
Search WWH ::




Custom Search