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

on the display so that users will know when they've found the answer. Depending on where the
interface's data comes from, this may be easy or hard. Sometimes in an electronic prototype it's
necessary to hard-code the data or create a test database; it may be easier to use a paper prototype
instead because you can simply write in whatever data you need. So consider the following: "Where
does the data come from? How easy will it be to have the prototype display the realistic data needed
for usability testing?"
Finding Technical Issues
Obviously, paper prototypes don't show you whether a design can be built (of course, other prototyping
methods may not either, unless they use the same development environment in which you're planning
to implement). Paper prototypes aren't constrained by existing architecture, databases, bandwidth,
legal considerations, business policies, the operating system, accessibility concerns, and so on. In real
life, developers must consider all these constraints and more. You don't want to create a prototype
that's impossible to implement.
Interestingly, even though there is no code involved in a paper prototype, it can sometimes help the
development team anticipate technical problems. Although software engineers naturally tend to think in
terms of database schema, software architecture, communication protocols, and the like, sometimes
they get technological tunnel vision and may overlook the implications that a particular user requirement
has for the design.
Here's an example from my own experience:
In the mid-1980s I was a project manager for the development of some internal tools for my
company's field technicians. We had spent several weeks hashing out database schema,
processing, and all sorts of technical innards. There were also to be some reports available to the
user, but we'd left them until last under the assumption that they'd be easy—reports simply take
information from database records and format it nicely, so what could go wrong with that?
But then the engineer assigned to program the report modules walked into my office scratching
his head. He couldn't figure out where Report X was supposed to get its data. We quickly
realized that, in fact, Report X was impossible to produce with the databases we'd designed.
D'oh! It took our five-person team about 2 weeks to revise the databases (and the code that had
already been built on them, as well as the specs) to recover from this snafu.
Would paper prototyping have found this problem? Although I can't rewrite history, I believe the answer
is yes. In paper prototyping, you first create a realistic set of tasks and then build the prototype to
support them, which forces you to visualize the entire process of what users will be doing. If we had
done usability testing on this project, we would have included the reports because users needed them
to see the results of their work. The problem with Report X was blindingly obvious the first time
someone looked at it—mocking up Report X would have put it on our radar screen before we'd spent all
that time developing a database schema that was incompatible with it.
Strictly speaking, paper prototyping doesn't deserve all the credit for unearthing this type of
problem—it's really walking through the tasks that allows us to see an interface from a user's
perspective. The paper prototype simply makes it possible for this to happen earlier in the development
process, when it's less painful to make changes. In working with many product teams over the years,
I've seen that it's common for technical questions about what can and cannot be coded to arise from
the process of constructing a paper prototype and using it to walk through tasks.
Now let's switch our focus from prototyping tools and interface development and start talking about the
people—first the users, then the product team.