The Politics of Paper Prototyping - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 235

Resource Constraints

I've never worked on a project that didn't have resource constraints; every development effort has limits
on the time, money, or people that can be devoted to it (usually all three). So it's natural that some
people are uncomfortable about anything that sounds like additional work, even if they recognize the
benefits. Chapter 5 covered the activities in a usability study and how to estimate the time you'll need.
But some of your co-workers' concerns may not be addressed simply by having a schedule for all the
activities. The main way to counter these kinds of concerns is to look for a point of comparison. In other
words, to ask, "How will paper prototyping affect us compared with what we're already doing?"

Let's

look at three common concerns.

Won't It Result in More Work?

If you're testing to find problems, you're going to find problems, and obviously someone will have to fix
them (or make a deliberate decision not to). It's hard to argue with the logic that the amount of time
you'll need to spend responding to user feedback is directly proportional to the amount of feedback you
ask for, which implies that paper prototyping (or any other form of usability testing) can result in
additional work, at least in the short term.

The key to this question is to agree on what your time frame is. If you don't do any usability testing and
problems with usability and functionality are found after release, you still have all the work associated
with fixing them, but this work happens in the next release instead of the current one. (Unfortunately,
this idea can be attractive to those who don't plan to remain at the company.) But you might be able to
think of examples where postrelease usability problems came to light and caused havoc for technical
support or were difficult to fix. In particular, look for problems of the types that paper prototypes are
likely to find and make the case that it would have been possible to fix them before release. But tread
carefully here—avoid sounding smug or berating others for mistakes that were "obvious" in retrospect.
If possible, consider choosing an example from your own work.

How Will This Affect Our Development Process?

You already have a development process in place. Even if your process is an undocumented, ad hoc
mess, it's still a process. Process simply refers to what you do, not necessarily what you'd like to do or
are supposed to do! Here are some questions that'll get you thinking about how paper prototyping
might alter the way in which you develop products.

"How long will we spend designing the interface if we don't do a paper prototype?" One
way or another, the interface has to be designed—and often redesigned. Paper prototyping may
not be so much an additional activity as a different way of doing something you're already doing.