Thinking About Prototyping - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 40

Designing
Design is probably the hardest activity of the three, and correspondingly it's hard for a prototyping
method—any prototyping method—to support it very well. As sophisticated as computers are, they're a
poor replacement for our creative problem-solving abilities, which is why interfaces are still designed
and developed by humans. Prototyping methods focus mainly on the rendering and coding aspects of
the process; they don't necessarily help us become better designers.
On the other hand, it's possible for a prototyping method to constrain the design process, as Alan
Cooper eloquently explains (see Of Interest box that follows). One benefit of paper prototyping is that it
imposes relatively few constraints on a design. The next chapter provides many examples of how to
construct various interface widgets. For now, proceed under the premise that paper prototyping will let
you make most anything you can envision.
Of Interest ... Excerpt from "The Perils of Prototyping"
By Alan Cooper, Chairman & Founder
August/September 1994
Originally Published in Visual Basic Programmer's Journal;
available at www.cooper.com/articles/art_perils_of_prototyping.htm
Software has a life of its own. It is full of little quirks and idiosyncrasies that influence how it is built. This
is true whether the tools are high-level (VB or HyperCard) or low-level (asm, C). Some things are easy
to build, and other things are hard to build. That this strongly influences the design is almost universally
unrecognized. If you take the great risk of building something divergent from the tool's strength, you will
quickly find yourself in a minefield of tactical choices:
"Hmmm, let's see, if I code it this way the user presentation is better but then I have to build my own
[giant-piece-of-reinvented-wheel], or I could code it the other way and have this operational conflict with
this store-bought gizmo that I need to make this other part of the program easy to do, or I could roll my
own and then it would be correct but I won't be able to test it for 6 months, or I could ..." None of this
has anything to do with software design!
Of course, any design process has constraints. Some things are hard to implement, and others are
impractical or even impossible. A good designer doesn't ignore constraints, but on the other hand you
don't want to choose a tool that introduces additional and unnecessary ones, especially early in the
process when you're trying to be creative. When considering a prototyping method, ask yourself: "What
does this tool make easy (or hard) to prototype? Will this tool affect my creativity? How much will it
distract me from thinking about the design?"