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

Coding
I once saw a demo of a tool that was touted as a fast and easy way to create interfaces. The guy
conducting the demo first put several controls on the screen in just a minute or two. Then he made an
offhand comment about "linking in some prewritten code" and jumped to a completed version of the
interface. Being a software engineer at the time, I immediately thought, "But wait—he's just skipped
over the hard part!"
Coding the behavior of an interface (and the underlying databases and processing required to produce
its outputs) is where the bulk of the work lies—90%, according to Joel Spolsky, a programmer who
writes a column on software development at www.joelonsoftware.com . I don't want to get hung up on
the exact percentage because it varies depending on the type of interface and also on the tool—a
software application may have very complex underlying code, whereas many Web pages have little or
none. But it's a reasonable generalization that most interfaces have substantial code beneath them.
In a paper prototype, the coding effort is always zero.
Joel explained to me why creating a working software prototype can actually take longer than making
the real thing. The problem is that you have to either reconstruct code or leave it out. If you leave it out,
you're very restricted in the kinds of tasks you can ask users to do, and thus you may not get good
feedback about the new functionality. If you reconstruct it, however, your software prototype can take
longer than if you'd just coded it into the real product. Joel offers this example:
Several years ago at Microsoft, the developers wanted to explore the usefulness and feasibility of
using drag & drop to move cells in Excel. They had a couple of interns work all summer to make
a prototype of Excel to support this functionality. Trouble was, to actually test it they needed to
implement a healthy chunk of the spreadsheet functionality so people could perform realistic
tasks—if they'd just done the drag & drop part, they wouldn't have gotten to see which method
people naturally chose in different situations. So they ended up recreating a good chunk of Excel
in order to make their prototype functional. When they usability tested it, they found that drag &
drop was indeed a useful thing for users, so they put it in the product. It took the staff
programmer about 1 week to implement in the product, as compared to the interns who worked
all summer on their prototype. The irony of this is that the whole purpose of a prototype is to save
time.
Joel also notes that you could always put new functionality into your code and take it out later if it isn't
what users need. But ripping out code can introduce bugs, not to mention that destroying one's own
work is a pretty unsatisfying thing to do.
As prototyping tools become more sophisticated, they'll grow in their ability to automate the behavior of
certain interface widgets—put a Submit button on a form, and it'll automatically do the right thing. But a
prototyping tool that could automate everything would in essence replace programmers, and I don't
think that will ever happen. In a paper prototype, a human simulates what the code would do. Thus, the
coding effort is always zero. No matter how sophisticated the prototyping tool or how proficient one is
with it, you can't get any faster than that. This is an important benefit of a paper prototype, particularly
for complex software—no code to write or (sometimes even more important) rewrite until the design
has stabilized. The flip side of that coin is that at some point you do have to start writing code, and
paper prototypes don't help with that.
To assess the importance of the coding factor for your product, ask yourself: "How much code is
required to support everything the user sees? How much of this work does the tool do for me? How
much of a pain will it be to change that code while the design is still changing? Do we plan to evolve
our prototype into the finished product, or is it okay to throw the prototype away when the real coding
begins?"
Don't forget the data. As Chapter 7 explains, if you plan to conduct usability tests of your design, users
will need to see realistic data to perform meaningful tasks. For example, if you want users to look up a
stock quote using your mobile phone interface, you'll need some way to make that stock quote appear