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

Rendering
There are many ways to render an interface. You can draw it by hand or do it on a computer using
Dreamweaver, Visual Basic, or any one of a myriad of tools. There are even tools like DENIM that let
you sketch an interface on a computer by means of a drawing tablet, which may initially seem odd but
as discussed in Chapter 12 , it does have some benefits. There are plenty of choices here. In thinking
about rendering, consider how much effort is needed with a particular method and how good the
prototype needs to look. The following sections address these issues in more detail.
Effort to Render
The effort needed to render a prototype varies not only with the method but also with the skills of the
individuals involved—drawing comes naturally to some people, whereas others may be proficient at
creating interfaces with software. There are three factors to consider regarding the effort required to
create a prototype and test it with users: creation, duplication, and modification.
Creation
How quickly can a screen be made the first time, starting from a blank slate? Some prototyping tools
give you a leg up because they provide a library of widgets, or maybe you've even developed your own.
Although it's possible for some people to mock up screens quite quickly using software, it's often
possible to draw that same screen by hand in even less time. From what I've seen, I believe that
drawing by hand is probably faster for many people, most of the time, but naturally there are
exceptions.
Duplication
Does your interface have many similar screens (for example, several online product pages that all
have the same layout)? How easy is it to make the variations? In software, this is pretty
straightforward—you load a template, put in the unique parts, and do a Save As. With a hand-drawn
paper prototype you can do the analogous process using a copy machine, so there may not be a
significant difference here.
Modification
When you discover a reason to change a screen, how quickly can you tweak it? If this happens in a
usability test, can you do it while the user is still present and thus get immediate feedback? An
interface doesn't just get designed, it gets redesigned as well, often many times before it's done. With a
paper prototype, you can make changes very quickly, even during a usability test. If a term is confusing,
you can cross it out and try a different one. You can write an example next to a confusing edit field. You
can write a sentence of explanation about the next step in a process. Simple changes like these can
solve many usability problems.
I once saw a developer (let's call him Ed) make changes on the fly to a working Web application.
During the usability tests, Ed sat in the room along with other observers. I thought he was just
using his laptop to take notes—little did I know that he had a connection to the development
server. Along came a task where the users became confused and clicked the wrong link. During
the post-task discussion, Ed asked the users to click Back and then Refresh. Voila! Up came a
new version of the page that solved the problem. Although Ed's real-time interface changes were
entertaining as well as successful, it's rare that this is feasible for developers to do with a
software prototype.
With some software prototyping tools it may also be possible to make quick changes, but think carefully
about the logistics of how this would work in a usability test. When the user finds a problem and you
want to make a change, you might have to grab the keyboard and mouse from the user, get out of the
running prototype and into the prototyping tool, make the change, and then get back into the same spot
in the interface (which may have been reached after a sequence of actions) to see whether your fix
works. One advantage of a paper prototype is that you can make the change without losing the user's