snyder_paper_prototyping_ch4

snyder_paper_prototyping_ch4 - Making a Paper Pr't'type...

Info iconThis preview shows pages 1–18. Sign up to view the full content.

View Full Document Right Arrow Icon
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 2
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 4
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 6
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 8
Background image of page 9

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 10
Background image of page 11

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 12
Background image of page 13

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 14
Background image of page 15

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 16
Background image of page 17

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 18
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Making a Paper Pr't'type I’m going to plunge into the topic of creating paper prototype widgets because most people like to see lots of examples while they’re learning about paper prototyping. But in real life, before creating the paper prototype you should first define the users and tasks and then build your prototype around them. The next chapter returns to the beginning of the process and discusses all the steps in their proper order. This chapter is meant to familiarize you with how many common interface widgets (and their behaviors) can be prototyped in paper. are Prototyping Water-id; Although it's possible to create a paper prototype with nothing but a pen and paper, several other materials come in handy. Most of the supplies used in paper rototyping (Figure 4.1) are available from your favorite office supply store. A few isms (such as the removable tape) may not be stocked in stores and are easiest to {1 online. See wwui paperprototyping.com for links to the supplies mentioned in ie 4.1. For lugging these supplies to meetings, old conference bags are ideal unless I‘B already using them for your groceries. You can also buy a plastic toolbox—— f my colleagues uses bright—colored ones and she notes that they attract a lot esitive attention at her company. '10 4) Chapter 4 Making a Paper Prototype use of common office supplies-those that are harder to find in stores Figure 4.1 Paper prototyping makes are readily available online. nd shown here, is useful in paper prototyping. lt come Figure 4.2 Removable tape, such as the Post-it bra in several widths. Table 4.1 Office Supplies Used in Paper Prototyping White poster board, about 11 x 14 inches Blank paper Unlined index cards, 5 x 8 and 4 x 6 Markers, pens (black and/ or colored) Highlighter Scissors Transparent tape (Scotch tape, invisible* tape) A fixed background upon which other paper prototype elements are placed. For drawing larger prototype pieces, jotting down notes, etc. Useful for smaller prototype pieces: dialog boxes, pop—up messages, drop—down menus, etc. Hand-drawing the prototype. Choose a thick enough point so that you’ll draw a bit larger than , life size—regular pens may be too fine, flip chart markers are too thick, Sharpie pens are about right. Used with transparency and re— movable tape to make a highlight element. Used to cut screen shots into pieces, as explained in the text. For attaching pfototype pieces permanently, such as creating a dialog box out of two index cards. For a less permanent attachment, use removable glue. Paper Prototyping Materials <> '11 Paper prototypes are usually some- what larger than life size. I buy 11 x 14 when I can find it or cut a 14 x 22 piece in half. It’s okay to use a lot of paper while creating a prototype, and keeping a stack of paper on hand reminds people of that. (Bring a recycle bin too.) Card stock is sturdier than regular paper and holds up better under repeated use. My local discount store sells sets of art markers for much less than I’ve found online. Light-colored translucent plastic would also work. Don’t run with them! A matte finish reduces glare, although this usually isn’t a prob- lem unless you’re videotaping. Continued '12 0 Chapter 4 Making a Paper Prototype n Paper Prototyping——cont’d Table 4.1 Office Supplies Used i glue marked Don’t confuse it with “washable,” which is no Difficult to find in stores. Like the glue on sticky notes, it keeps elements of the prototype t restickable, : in place until you’re ready to move them. Useful in experimenting with different layouts or if your prototype has elements that change individually, such as a Web site that uses frames. u can write on A paper prototyping essential—— for an example. I use enough of this stuff that I’m d Use the 2—line width for edit tempted to buy stock in BM. fields (espeCiauy if the dala Turning a corner under makes it appears elseWhere m the mtm' easier to lift the tape off the paper face), small amounts of text that when you want to move it change, status line messages, elsewhere list elements. The 6—line size is good for dis- abled buttons and quick fixes to the prototype. Placed over the prototype, it ” (hand write) data without alterin prototype. Figure 4.3 shows an example of removable tape. 1 use transparency when there are more than a half dozen fields to cause glare__use CO complete, otherwise I use remov- forms instead able tape. Permanent transparency pens For writing “typed” input on a piece of transparency laid on top but since you can’t erase ets of of the prototype. Use damp paper towel or cotton swabs as an “eraser.” ’ , Restickable glue It’s opaque so yo Removable tape it. See Figure 4.2 (Post—it is avail— able in 2—line an 6-line widths) on transparency rather Get write— ser than the stuff intended for la Transparency much more (overheads, acetate) printers, which is expensive. ing in a lab with an ’ , transparency can ' pies of the paper ' work too, them you’ll use more she transparency. Transparency pens, wet erase Paper Prototyping Materials <> 73 Table 4.1 Office Supplies Used in Paper Prototyping—cont’d Correction fluid (Wite—Out) For small changes to the proto— type, such as afield label. Fome-Cor board For making 3D prototypes. It’s polystyrene form sandwiched between two sheets of thick paper. You have to let correction fluid dry before writing on it. In a usability test, I prefer to use removable tape to make quick fixes. You’ll sometimes see it spelled “foam core,” although Fome-Cor is actually a brand name. Other com- panies make similar products. * For those who enjoy visual humor, buy a roll of “invisible” tape, remove the tape, and hang the backing card on your bulletin board. éfls 16% (wine-a? Wee. Figure 4.3 This prototype shows the use of both removable tape (line items) and transparency (the total). In this example the Computer wrote these elements on the fly to show the results of the user’s actions; on screens with data entry fields the users would write on the tape or transparency themselves. er Prototype s I Don’t Use Supplie type itself, althoughi There are a few items 1 generally don’t use in the paper proto sometimes use them in related acti 'ties with the product team. 0 Sticky (e.g., Post-It) notes. They don’t lie fl times, so I avoid using them in prototypes. glue, which essentially lets turn anything into are often useful in ity testing), however, Although i suggest making paper prototypes larger than fife; ' ine tried it and reported; flip chart paper is pr their heads, which : that users couldn’t see introduced artificial confusion. On the other hand, flip chart paper is great for scribbling design ideas, making to-do lists for the team, and so on. O A ruler. Straight lines usu aren’t important for a hand-drawn paper prom» type. When 1 was at User Interface Engineering, we used to include rulers in our paper prototyping supply kits, but we found that they encouraged people to waste time by making their pro at. I advise using a ruler nment is important, a t is truly that importmt,’ only if exact alig nd if alignmen the interface should probably be rendered using software instead of being hand—drawn. <> Fine-tip pencils or p use fine—tip writing in fortable working in pen est drafts, but then draw th 0 Laminator. I’ve heard of people who laminated their prototype pieces to m f them sturdier and/ or so users could write on th idea if y u happen to have a laminator handy, but I wouldn’t b this pu pose. One drawback is that you can’t alter alarn paper—«removable t but correction fluid doesn’t. m a “Bachqu underneath your prototype piece It can be helpful to create a background to go usually use a piece of 11- x 14—inch poster board for the background because '% both sturdier and larger than a piece of regular paper. The background stays % een moved a few , at after they’ve b I prefer card stock and restickable , <> Flip chart paper. observers to read, so don’t ens. Fine lines are difficult for em with awet-erase pen. Afl I uy one just inated piece as easily ' ape works, Creating a Background 0 75 the table, and you put the other pieces of the prototype on top of it. Why might you use a background? 0 It helps orient the users that they’re looking at a representation of a computer screen or other electronic display. This isn’t always necessary, but it may be helpful with less tech-savvy users. If controls appear on every screen, you can draw them on the background and omit them from the individual screens. (And if you change those controls, you only have to change them in one place.) When you’re usability testing, you’ll have prototype parts spread out all over the table—the background helps you keep track of what is currently visible to the user versus what you’ve set aside. It provides a reality check for screen real estate. In paper prototypes of soft- ware or Web sites I normally don’t worry about exact proportions. But if an interface is composed of multiple windows and the prototype pieces spill way over the boundaries or users repeatedly move pieces on top to see the ones beneath, it’s time to start worrying about screen real estate. If you’re videotaping, you can tape the background to the table so that the prototype will stay in the camera’s View. A background is not always necessary. If you’re testing a Web site and you’ve made screen shots that include the browser buttons, you don’t need a separate background. On the other hand, if you’re prototyping the display for a small— screen device, you’ll probably want a background or blinder (as described later in this chapter). ftware Application Backgrounds First, decide whetherfithe background should represent the underlying operating system or just your application. If your application is the only thing you’ll be test— ing, you can use its main window as your background. You might want to start from the operating system if you’re testing multiple applications at once and/ or want to verify that the user can launch the application. In this case, draw enough of the familiar operating system elements to orient users. For example, for a Win- dows desktop, I’ll draw the Start button and clock at the bottom and a few com- mon desktop icons like My Computer. Figure 4.4 shows an example of a Windows application background where the desktop elements were not deemed necessary. '16 0 Chapter 4 Making a Paper Prototype Figure 4.4 A background for a Windows application (the Palm Desktop] drawn on a large piece of paper. The menu bar, toolbar, and left-hand buttons appear on every screen. All other prototype pieces are placed on top of this background. Note that the toolbar icons have been replaced by their corresponding words. Browser Backgrounds For a Web browser, the version or brand isn’t relevant in paper prototype testing. As a rule, you need only the most common browser buttons: Back, Forward, Home, and maybe Print or Search. In my experience, users understand these but- tons jugt fine when they’re drawn by hand; a screen shot of real browser buttons is often harder to read. Figure 4.5 shows an example of a browser background. I usually omit the buttons for Stop and Reload—these browser controls aren’t needed for paper prototype usability tests because there is nothing to “down— load.” Similar logic applies for omitting bookmarks and the URL field—if you’re testing a specific Web site you’ve probably made the assumption that the user got there by some means that’s outside of what you’re trying to test. I typically start the usability test by telling users, “You’ve opened your favorite Web browser and typed in www. whatever com.” In my experience most users don’t navigate within a \\ / \\\\,\\\\\\\\\\ / Creating a Background 0 '17 Figure 4.5 A background for testing a Web site can consist ofjust the most common browser buttons. The browser brand or version isn’t important—this background says internet Explorer" simply to inform users they’re looking at a Web browser. Web site by hacking the URL field (and if we’re trying to test the site’s navigation, we don’t want them to), so I feel pretty safe leaving it out. We Mrmftiowr about howwrer; wilb merryootr site beam/ore “KW/'0! M be wrong. It com, be m ale/opener to rthrt w mobility 1by showing Loser: Mead/or olirectwwibfiecewed/tofromotetheritem them, “Howwoodob ow thbr?” Ohe ofwyfirmer cheat: was t—Hf/ MW that jmt waded 100, 000 brochurerfir the phi/pore of ' trofieto thew riteohobthehbro htmeihto do romewmb' ' tat— Mrfirthhateél, #Le MR1. wow so how“ to out ry‘the brochure most (who wereqhoteihtererteobiwthecohceftzftherite) comb/{hth ’ob tin/to et there. Itert— co ' omit rob error: thigh/>35; timejl Visited the epoZwbnzltAZ/the mob 00W “rm through million; of [bars and weht out ofbom'mm.” A note for both software applications and Web sites: If you’re placing several prototype pieces on a background, users sometimes get confused as to whether they’re looking at several different windows or one window that happens to be W 78 0 Chapter 4 Making a Paper Prototype made up of several pieces of paper. When I see this happen, I simply tell users, “This is all one screen,” which usually alleviates the confusion. Small-Screen Interfaces In prototyping a small—screen device such as a personal digital assistant (PDA) or wireless phone, sometimes pixels count. When screen real estate is scarce, you may want to incorporate display constraints even for your initial prototyping ef- forts. It depends on what you’re trying to learn from usability tests; in the early stages when you’re still trying to understand users’ needs or nail down the func- tionality, size may not be as critical as it is in the later stages of the project. Follow- ing are examples of two people who chose to do things differently, and why: E From the Field: The Importance of Screen Real Estate “My company develops applications for PDAs such as Pocket PC and RIM, and also for wireless usage. I’ve found that sometimes it’s im- portant to have the look and feel of a specific environment—in our case the developers have experience with other platforms but they're not always familiar with how various widgets appear on the Palm vs. \Pocket PC, etc. By creating platform-specific widgets in a graphics application, it helped them understand exactly what they needed to implement." PW Haw/b, Hmm “We used a paper-only interface back when we were still in the early stages of designing a browser/phone combination. We wanted to understand what tasks worked well in this type of interface, and to determine the appropriate set of buttons that would work for both lfiavigation and phone functions. It would have been premature to worry about screen size too much while we were still in the explora- tory phase.” TWJokeZao/trmaréx ofNokia/ If you decide you need to worry about size constraints, one way to do it is in a graphics program: Start with a photo or screen shot of the device, create a file for each individual screen, and then print them out for testing. For example, here’s \\\\\\\\\ Creating a Background 9 79 how Phillip Hash created the prototype just described: “My approach for hand- held devices is to first grab screen shots of applications running on those devices, such as my Pocket PC. Then I’ll open those images in Fireworks and overlay wid- gets on top of them.” The paper prototype of the xpressa interface shown in Chap- ter 2 was created in a similar way. Hal Shubin started by downloading a Palm Oper— ating System Emulator (even though he wasn’t prototyping a Palm interface, it gave him something of about the right dimensions to work with). A graphic de- signer created a mock-up of the entire telephone and gave him back a set of GIF files. Hal used PhotoShop to create the paper prototype—the phone image was the background and he created overlays for each different screen. Figure 4.6 For a small—screen device where size constraints are important, you can make a blinder using a photograph of the device, somewhat larger than life. Use hand-drawn content on an appropri- ately sized grid for the display. 80 0 Chapter 4 Making a Paper Prototype It’s possible to avoid using a graphics package altogether but still keep screen constraints in mind. In his book Handheld Usability, Scott Weiss describes how to make a “blinder” for a small-screen device: “The key component of a prototype of a handheld device is the blinder, which is a sheet of card with a drawing of the hardware device with a cutout where the display would be. The size of the cutout is important because it models the amount of data that can be displayed without requiring scrolling. In order to support scrolling, the card must be larger than the drawing of the hardware device” (Weiss, 2002, p. 139) (see Figure 4.6). By using a grid (such as graph paper) for the display area, it’s possible to accurately represent the number of characters that are visible but still draw them by hand. (Or, if. it’s faster, figure out an appropriate size font and type the data instead.) Fmtotype ?utec-lace “Wet; Once you’ve created a background, the next step is to create each screen that will be placed on top of it. Figures 4.7 through 4.15 demonstrate how you can proto- type the most common interface widgets. :m B W“: rm _ a»; , ffii‘ urged- ‘lmi‘ {I $.23 M“. ‘ Buttons and checkboxes Removable tape works well for radio buttons and checkboxes—~ the user touches the desired option, and the Computer moves or adds the piece of tape. Sometimes users will catch on and simply move the radio buttons themselves. Figure 4.7 Radio buttons/checkboxes. Figure 4.8 Tabbed dialog boxes. Tabbed dialog boxes Because a tabbed dialog box is a metaphor for a stack of index cards, prototyping them with a stack of index cards works quite well. Draw each dialog box on a separate index card, then stack them on top of each other, using removable tape to make the tabs. When the user clicks one of the tabs, simply move that card to the top of the stack. Multiple rows of tabs can get a bit cumber— some—you can still use this approach, but you’ll spend more time aligning your stack of cards. How to Prototype Interface Widgets O 81 Text fields Removable tape works well for text fields. The user writes on the tape, which the Computer can reuse elsewhere in the interface. In this example, the user is naming a table, so this name might appear in the list of defined tables. Note: For forms, it may be eas— ier to place a piece of transparency over the entire form and have users write on that or to let them write directly on a paper copy of the form. as ' in fine. Figure lLlO Drop-down lists. Drop-down lists Write the default selection on the paper prototype (for example, "choose one") and put the list on a separate piece of paper. When the user clicks the down arrow, the Computer shows the list. Once the user makes a selection, the Computer writes it on a piece of removable tape and sticks it on top of the default. (The Computer may want to prepare the options that the user is likely to select ahead of time, or the Computer can create them on the fly.) Selection bar/highlight To show which element in a list is highlighted, make a highlight from a gfece of transparency that you’ve colored with a light— color marker. (Some markers don’t work well on transparency—— the ink will puddle—but all you need is a hint of color.) In addi- tion to the highlight at the lower left to indicate the Arrange- ments section, this image also shows a dark color rectangle that is used to highlight the Flowers tab. Figure 4.1] Selection bar/highlight. 82 0 Chapter 4 Making a Paper Prototype m * new gig Expandable dialog boxes cl") “WE Egg For a dialog box that has a More button or is otherwise expand- . able, you can cover the expanded part with blank piece of paper am 21an go containing the button that causes it to expand. (Or you can fold 9-“ “Wm m the screen so that the additional options are not initially visible— EEEZE a dab of restickable glue helps it lie flat.) When the user clicks the South [@128 a mu m button, remove the blank paper or unfold the screen to reveal the U Fm} ulnltwak ale . . a mi? expanded part, and change the button, In th1s case to Less. ‘3 :J fi‘M-fimc Figure 4.12 Expandable dialog boxes. [El {:3 m3 s23 6:» it; Expandable 1”“ f Ci} Emit : El gt” Cut the list into pieces and use remov— i “j” p g l C1 OWN“ able tape (or glue) so that you can sepa— " W m wklglm EMS/t" rate parts of the list and add the ex- , m 174:) We“: panded portion. You don’t necessarily i (24*de gulf: have to support the expansion of the l3ij {3%.} “3M5 entire list; after you’ve created the . , , 1 tasks and walked through them a cou- ' ‘ I L‘ ple times, you should have some idea of which items the user may wish to expand. Figure 4.13 Expandable lists. Disabled controls If a menu option, button, or other control is initially disabled until the user does something, make a ver— sion on removable tape with a gray marker and place it over the same element in black. Once the user has done what’s necessary to make the functionality avail- able, remove the grayed version to reveal the enabled version underneath. (In the example shown, there is still tape covering the word “Can’t” before Undo and Repeat.) Figure 4.14 Disabled ("grayed-out”) controls. WWW Representing the Users’ Choices 0 83 Cursors I don’t bother to prototype the standard arrow or I-beam cursors—this level of detail isn’t needed for most paper proto- type tests because the user's finger (or pen) shows where they’re clicking or typing. If your application uses cursors to convey information (for example, an image editing application that dis- plays a different cursor depending on the mode), draw them on small pieces of paper or transparency and place the current one are 4.15 Cursors. . . Fig somewhere on the interface as a Vlsual cue for the user. Wléprobaégx want to have m hoot/jinx: wrorfir those W when/the mar the Computer Ifyowdmwtha how W: larger thaw lgfiowm l x Wdz, Mar: Many/12W my, “Hg/,th ' my I’M computer!” ; Repregeutiuq the use!!! Choice; You might be wondering how important it is to accurately represent the state of each radio button, list, selection, and so on. Usually it’s pretty important because otherwise you’re asking the users (not to mention the Computer and the observ- ers) to remember all their choices. This cognitive effort makes the task harder and can result in artificial confusion. Sometimes it's also possible to miss subtle prob— lems unless you have responded to all the user’s actions in the exact order they happened. Figure 4.16 shows a prototype of a screen used to create a rule for filtering email. As the user selects each Condition and Action, the Computer writes it on removable tape and places it at the bottom. Note that the removable tape initially says, “where the from line contains people." After the user clicks on the link and selects a name frofh the address book, the Computer places another piece of tape on top of the word people to show the selected name. In this manner the user sees the rule being built one component at a time, much as it would appear on a com- puter. Because many actions are possible on this screen and they can be done in any order, the pieces of removable tape at the bottom help everyone keep track of exactly what the user has done. You might also be wondering how hard it is for the Computer to remember each correct response. The good news is that I believe it’s probably easier to make and use a paper prototype than to read about how to do it. The Computer is usu- ally someone directly involved in the design and thus knows a lot about it. As ¢ 81:- 6 Chapter 4 Making a Paper Prototype Figure 4.16 As the user specifies each component of the mail filtering rule, the Computer writes it on pieces of removable tape so that all the user’s actions, in the sequence they happened, are shown in the interface. explained in Chapter 7, the Computer practices the tasks before the first usability test, and this also helps. (As a consultant, I have helped product teams make paper prototypes of many interfaces that I initially knew nothing about. After watching a few run—throughs, I usually learn enough about how the interface works that I could be Computer if necessary.) versus 5W“ 5W a’ Of all the examples of paper prototypes in this book so far, you may have noticed that most of them are hand-drawn and rather messy. That’s deliberate; I wanted to emphasize that you don’t need much artistic ability to create a paper prototype. Paper prototypes are very good at unearthing problems with concepts, terminol— ogy, workflow, content, and so forth. These types of problems are often readily apparent even without an exact Visual representation of the interface. Although you may ultimately need artistic ability to create a good interface, you don’t neces- sarily need it to create a paper prototype. MMMWWWW» - - Simulating Interaction <> 85 Similarly, it’s usually appropriate to draw in monochrome and to fake most of the images and art—instead of the company logo, draw a box with the word “logo” in it, use a word instead of an icon, and so on. The only time I recommend against faking graphical content is when it conveys information needed for the tasks. For example, on a clothing Web site I’d use pictures of the products (perhaps cut out of a catalog) because it’s important to users to see pictures of the merchandise. If you’re wondering whether it’s okay to use screen shots in a paper prototype, the answer is yes. Chapter 7 provides more information about whether to use screen shots or hand-drawn paper prototypes. flute: When I say that paper prototypes can be hand-drawn, messy, and mono— chrome, some people get the mistaken idea that I don’t believe in the value of professional graphic design. Nothing could be further from the truth. Graphic design is both a skill and an art, and I have a great deal of respect for people who do it well. I’ve found that good graphic designers often embrace paper prototyping because it gives them valuable input for creating the lay- out and look of the interface. Usability testing will show them which design elements need to be emphasized or downplayed through the use of color, font size, white space, images, and so on. So I’m not anti-designer—in fact, people who see graphic designers as the ones who make an interface pretty are the ones who trivialize the skill. 5imuflatiuq S‘utemtiou The paper prototyping motto is: “With a little imagination, you can simulate almost anything.” There are many aspects of human-computer interaction that a human being can simulate well enough that usability testing provides useful feed- back. But complex or subtle interaction usually can’t be simulated perfectly; as Chapter 12 discusses in detail, this is a drawback of paper prototyping. 2‘ 0 Tooltipslmouseovers. Tell users at the start of the test that the real interface will have tooltips (a.k.a. “those little yellow boxes that pop up”) to explain the icons. Tell them that if they want to see the tooltip for an icon, they can point to it and ask, “What is this?” and you’ll tell them What the tooltip would say. Rollover/pop-up menus. These are conceptually similar to tooltips but are harder to simulate orally because a whole menu pops up instead of just a word or three. On a computer, I’ve found that What most users do is click to make the menu drop down, and then click again to make the selection. This works well 86 0 Chapter 4 Making a Paper Prototype enough to show you what option the user would select, but it will also mask some of the subtle problems that can occur with rollover menus. 0 Beeps. Simply say “beep” Whenever the computer would, for example, when the user clicks outside a modal dialog box. <> Drag 8: drop. This interaction is a bit difficult to simulate perfectly. Keep in mind that many users never even try to use drag & drop in an unfamiliar inter- face—~they use the menus instead—so it may not be something you need to worry about. But if drag & drop interaction is an integral part of your interface, ask users to specify what they’re dragging and where they’re dropping it. The Computer then talks through the visual changes that occur during this pro— cess. (“As soon as you move into this area, the cursor changes to this, and when you release the mouse you see . . .”) <> Right mouse menus. Tell users at the start of the test that right mouse menus exist, and if they want to see one they should tell you that they’re clicking the right mouse button, and then you’ll display the menu. As with drag & drop, don’t be surprised if no one tries to use right mouse menus in an unfamiliar interface. <> Sliders, progress indicators. I don’t usually bother to make widgets for progress indicators because they can be simulated verbally, for example, by telling the user, “A progress indicator comes up. It says 20% . . . 60% . . . done.” (Or “1% . . . 2% . . .”) If you need a slider for some other purpose (such as a user input device), cut two slits in a piece of paper and use a strip of paper for the slider. 0 Animation and video. Rapidly changing images can be hard to simulate. Sometimes it’s easiest to describe to the users what they’d see on the screen; other times a still picture (or a series of them) will suffice. For short video clips, consider using a video player to show the video, as one product team did when they were testing their multimedia Web site. 0 Web site links. When I first started paper prototypingWeb sites, I’d take a high- lightgé’r and highlight everything that was clickable—text links, buttons, image maps, and so on. As you might imagine, the pages looked pretty garish and all that highlighting proved to be more distracting than useful. It was also extra work, so I dropped that idea. Now I tell users at the start of the test that they if they’re not sure whether something is a link or just a picture, they can point to it and ask, “Is this a link?” and we’ll tell them yes or no. (Or, “It wasn’t originally, but apparently it should be.”) ...
View Full Document

This note was uploaded on 01/12/2010 for the course CS 147 at Stanford.

Page1 / 18

snyder_paper_prototyping_ch4 - Making a Paper Pr't'type...

This preview shows document pages 1 - 18. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online