Read an Excerpt
Paper Prototyping
The Fast and Easy Way to Design and Refine User Interfaces
By Carolyn Snyder
MORGAN KAUFMANN PUBLISHERS
Copyright © 2003 Elsevier
All right reserved.
ISBN: 978-0-08-051350-8
Chapter One
Introduction
Paper prototyping is a widely used method for designing, testing, and refining user interfaces. In the early 1990s it was a fringe technique, used by a few pockets of usability pioneers but unknown to the vast majority of product development teams (and often considered pretty darn weird by the rest). But by the mid- 1990s, paper prototyping was catching on. People at well-known companies (IBM, Digital, Honeywell, and Microsoft, just to name a few) experimented with the technique, found it useful, and started using it as an integral part of their product development process. As of 2002 paper prototyping is not considered nearly so weird, and the technique is mainstream practice at many companies, both large and small. There are, however, still many people who've only heard enough about paper prototyping to be intrigued—this book is for you.
For much of its history, paper prototyping has been a tool clenched firmly in the hand of the academic researcher or usability specialist. Like any useful tool, though, its greatest potential can be realized by placing it in the hands of nonspecialists along with instructions for its proper use. I believe that anyone who is involved in the design, implementation, or support of user interfaces can benefit from paper prototyping because it fosters development of products that are more useful, intuitive, efficient, and pleasing. Although you can't learn everything about a topic from one book, this one gives you enough knowledge about paper prototyping to start using it.
What Is Paper Prototyping Anyway?
In its broadest sense, paper prototyping can be considered a method of brainstorming, designing, creating, testing, and communicating user interfaces. This book emphasizes the creating and testing aspects of paper prototyping, although I touch on the others as well. The technique is platform independent and can be used for Web sites, Web applications, software, handheld devices, and even hardware—anything that has a human-computer interface is a potential candidate for paper prototyping.
I'm not aware of any official definition of paper prototyping, and I've heard people use the term in reference to several different methods. Here's the definition of paper prototyping I use in this book:
Paper prototyping is a variation of usability testing where representative users perform realistic tasks by interacting with a paper version of the interface that is manipulated by a person "playing computer," who doesn't explain how the interface is intended to work.
Here's how it works: You meet with other members of your product team to choose the type of user who represents the most important audience for the interface. You determine some typical tasks that you expect this user to do. Next, you make screen shots and/or hand-sketched versions of all the windows, menus, dialog boxes, pages, data, pop-up messages, and so on that are needed to perform those tasks. It is not necessary to have a working version of the interface. If you can sketch it on a whiteboard, you can make a paper prototype of it. Figure 1.1 shows an example of a hand-drawn paper prototype screen.
After you create the prototype, you then conduct a usability test. You bring in a person who is representative of the audience you and your team members agreed on. You ask this user to attempt the tasks by interacting directly with the prototype—"click" by touching the prototype buttons or links and "type" by writing data right on the prototype. One or two of you play the role of "Computer," manipulating the pieces of paper to simulate how the interface behaves but without explaining how it is supposed to work. A facilitator (usually someone trained in usability) conducts the session while other members of the product team act as note-taking observers.
You will quickly discover which parts of the interface work well and which are the trouble spots. Because the prototype is all on paper, you can easily modify it right after—or sometimes even during—each usability test. You can conduct several usability tests in just a day or two, and it doesn't take long to see the patterns in the feedback you're getting. Thus, paper prototypes allow you to iterate and improve a design quite rapidly based on input from real users, and this can all happen before the first line of interface code is written.
The previous discussion makes reference to four roles: user, facilitator, Computer, and observer. Figures 1.2 to 1.8 show these four people in action. (With the exception of the facilitator, there can be multiple people in each role, especially observers. So this is a minimalist example, but still a realistic one.)
What Paper Prototyping Isn't
There are three techniques—comps, wireframes, and storyboards—that people commonly confuse with paper prototypes. These techniques are useful, but they usually don't fit my definition of a paper prototype, although all of them can be turned into paper prototypes. Here's a bit more explanation.
Comps
Comps (which is short for compositions) are visual representations—usually of a Web site—that show the look of the interface, including colors, fonts, layout, logos, artwork, and so on. (Figure 1.9 shows a sample of some comps.) The graphic designer or agency responsible for the visual aspects of the design might make several variations of the interface, allowing the decision makers to pick the one that best supports the current business initiatives, conveys the brand, and so forth. Some comps use nonsense words to represent the text and links. Comps are primarily used in internal discussions of a site's visual design; they usually are not intended {or suitable) for usability testing because users can't interact with them. However, if comps contained realistic content and were printed out, they might then fit my definition of a paper prototype.
Wireframes
Like paper prototype, wireframe can be a confusing term because people use it to mean different things. A wireframe defines the page layout for a Web site, showing what content goes where. (Figure 1.10 shows an example of a wireframe.) In the early stages of designing a Web site, wireframes are used in determining the page layout and navigation. But is a wireframe a paper prototype? It depends. Some wireframes designate the major areas on the page with labels (for example, "product information") but don't contain any content. This type of wireframe is sometimes used to get feedback from users, but this approach is of limited benefit because it's hard to tell whether the user's understanding of "product information" is the same as the designer's. Thus, a wireframe without content doesn't quite fit my definition of a paper prototype. On the other hand, with the addition of realistic content a wireframe could be printed out and tested as a paper prototype. In that case I would classify the wireframe as a paper prototype.
Storyboards
A storyboard is a series of drawings or images that represents how an interface would be used to accomplish a particular task. It's basically a flowchart. Some storyboards, like the one in Figure 1.11, include representations of the user interface, but other storyboards are more conceptual and high-level. As the name implies, storyboards are often spread across a wall. They are typically used to understand the flow of the user's work and how the interface will support each step. Storyboards are most often used within the development organization, although sometimes users review them. Because users can't interact with storyboards (they can only look at them), I wouldn't classify them as paper prototypes. However, you could readily turn a storyboard into a paper prototype by taking it down from the wall and adding whatever data is needed to support a task scenario.
Benefits of Paper Prototyping
Here's a preview of paper prototyping's advantages:
* Provides substantive user feedback early in the development process—before you've invested effort in implementation.
* Promotes rapid iterative development. You can experiment with many ideas rather than betting the farm on just one.
* Facilitates communication within the development team and between the development team and customers.
* Does not require any technical skills, so a multidisciplinary team can work together.
* Encourages creativity in the product development process.
Someone once asked me what the paper prototyping "bumper sticker" would say, and my answer was, "Maximum Feedback for Minimum Effort." That's really what it boils down to—an efficient means of getting make-it-or-break-it information about your interface. Using only a few office supplies and a dash of ingenuity, you can get all sorts of useful feedback in time to do something about it before the next release.
Of course, no technique is perfect, and this includes paper prototyping. One important drawback is paper prototyping's difficulty in detecting some classes of problems. In addition, depending on the circumstances of the project, there are cases in which the benefits of paper simply aren't very compelling.
Paper Prototyping and Usability
Entire books are devoted to usability (a.k.a. user-centered design). Although I can't summarize the entire discipline in a few paragraphs, I've found it helpful to think about usability in the following ways:
* The goal of any user-centered activity is to make the interface better for its intended audience and purpose, in a way that is consistent with the business goals of the organization producing that interface.
* Usability is like love: The more you give away, the more you have. You can help spread the love by passing along the concepts in this book to others. It'll come back to you in the form of more successful products.
* Usability is also similar to pornography in its ability to elude precise definition. To paraphrase the famous line by U.S. Supreme Court Justice Potter Stewart, "I know usability when I see it." If you do much reading about usability, you'll come across many definitions of it (some more usable than others). Don't get bogged down in the semantics; you'll be able to recognize good usability before you can define it.
* Like Don Norman says, a usable interface becomes invisible; sometimes you know you've gotten it right when your customers/users don't talk about how usable the product is ... they're too busy raving about how you've made their life better.
Readers familiar with usability may notice that I tend to view paper prototyping and usability testing as overlapping and often synonymous concepts. But that's a generalization, and like any generalization it isn't entirely accurate. Many companies create prototypes in software and conduct usability tests with them. Paper prototypes also have uses beyond usability testing, such as internal reviews. But most of the time when I use the term paper prototyping, I assume that the prototype is being created with the intent of usability testing it.
The History of Paper Prototyping
I've been using paper prototypes since 1993, but I didn't invent the technique. Neither did Jared Spool, whom I learned it from during my consulting days at User Interface Engineering. But determining where paper prototyping originated is like trying to track a river upstream to a single source. The best I can do is point out some of the tributaries.
If you peruse the References section or do an online search, you'll find the concept of "low-fidelity" prototyping popping up circa 1990 from authors like Jakob Nielsen, Bob Virzi, and Tom Tullis, to name just a few. A few people in high-tech companies were using the technique during the 1980s and earlier (Chapter 2 has some interesting examples courtesy of Robin Kinkead). As far as I can tell, the method was around for a decade or two before it showed up on the radar screen of the average person (such as yours truly) involved in product development.
(Continues...)
Excerpted from Paper Prototyping by Carolyn Snyder Copyright © 2003 by Elsevier. Excerpted by permission of MORGAN KAUFMANN PUBLISHERS. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
