Making a Paper Prototype - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 69

Beyond the Computer Screen-Incorporating Other Elements
A user interface isn't just what appears on the computer screen—in the broad sense it includes
everything that users interact with during the process of accomplishing their goals. That could include
printed manuals, online help, other reference materials, hardware devices, and even human beings.
And some interfaces have buttons and knobs instead of graphic user interface widgets. So let's look at
how you incorporate these elements into paper prototypes.
Hardware Props
Sometimes the interface includes hardware devices in conjunction with software or a Web application.
For example, portable gadgets (such as PDAs, digital cameras, and audio players) have a cable
connecting them to the computer, and these devices have interfaces of their own. If a hardware device
is an integral part of a product, you may want to include it in your paper prototype tests (see Figure
4.18 ). Obviously, users will be able to see that the device isn't connected to anything, but you can still
learn a lot about how they'll interact with it. Here are some examples:
Tape backup system. The development team wanted to know the point at which the user inserted
or removed a tape, and when and how they labeled it. So we put a tape drive on the table next to
the prototype, along with some blank tapes and a pen, and asked users to use these items as
needed. One of the developers wrote "Whirrrr!" on a card to represent when the drive was making
noise—funny, but also useful feedback for the users during testing.
Portable MP3 player. We wanted to know when users would connect the physical device during
the process of downloading music and whether they'd use it or the Web application to perform
functions such as deleting individual songs.
Touch screen control panel. This example is ironic because we used a computer as a prop for a
paper prototype test. To correctly install a touch screen, the users (computer technicians) had to
plug it into the same port they had chosen in the installation software we were prototyping. We had
a computer and cable in the test room, and we asked users to physically plug in the cable. We
noted which port they used to determine whether they'd done it correctly. In another task, we
wanted users to troubleshoot a hardware problem—a jiggling cursor caused by a frequency
conflict—that was hard to explain but easy to show. Again, we used the computer to demonstrate
what the cursor problem looked like but had them solve it using the paper prototype.
Figure 4.18: If a software interface works in conjunction with a hardware device, you can set it on
the table and have users interact with it as part of the prototype.
One hardware prop that I don't use is a keyboard for typed input. I've never found it necessary; it's
adequate to simulate most data entry by having the user write it with a pen. Sometimes it's important to
know what key a user pressed—for example, Tab versus Enter to get to the next field in a form. To
determine this, the test facilitator can simply ask, "What key did you press to get there?" (But once the
user has given a correct answer, there's nothing further to be learned from asking this question for