Organizational Information

jerrs ranging fiiom the basic meLa- Now considrr a diffcrrnt situation, phor to the choice of background one I have witnessed first-hand over color. The team .just barely has time the past few months: a development to incorporatr these comments into a team spends weeks designing an in- rwiscd design brforr committing terface. During the first few days,

they construct a paper prototype of their initial thinking about all aspects of the design, and test it with typical

by Marc Rettig representatives of the user commu-

nity. One of them “plays computer,” moving components of the paper in- terface around on the table in re- sponse to the users’ actions. The oth-

ers observe and take notes. After the tests they take a week to distill lessons from their observations, redesign the interface, and retest with several new users. This process continues until, at the end of the time allotted for inter- face design, the team has revised their design four times and tested it with many typical users.

This technique-building proto-

types on paper and testing them with real users-is called low-fidelity pro- totyping or “lo-t7 for short. The value of promtyping is widely recog- nized, but as thr first situation exenl- plilies, that value is not always gained in practice. If that has brrn your ex- perience, you might want t” try lo-C promtyping, which requires little more in the way of implementation skills than the ones you learned in kindergarten.

The idea oflo-fi prototyping (a.k.a. “paper prototypes”) has been around a long time. So long, in fact, that nmre than one person in the CHI community expressed surprise when I said I was planning to write a col- umn on the subject. But I see this as a wonderfully simple and effective tool

that has somehow failed to come int” general use in the software commu- nity. I say this based on the success of the teams I’ve watched over the past several months together with the fact that this is the first commercial proj- ect where I’ve seen paper prototypes employed.

Paper prototyping is potentially a breakthrough idea for organizations that have never tried it, since it allows you to demonstrate the behavior of

an interface very early in develop- ment, and test designs with real users. If quality is partially a function of the number of iterations and reftnements a design undergoes before it hits the street, lo-fi prototyping is a technique ,that can dramatically increase quality. It is fast, it brings results early in de- velopment (when it is relatively cheap

to make changes), and allows a team to try far more ideas than they could with high-fidelity prototypes. Lo-fi prototyping helps you apply Fudd’s first law of creativity: “To get a good idra, grt lots of ideas.”

The Problems with Hi-Fi For years developers have used ev- erything from demo-builders to mul-

timedia tools to high-level languages to build prototypes. Lo-fi proponents call these “hi-h prototypes.” They have their place: selling an idea, test- ing look-and-feel, detailed proof-of- concept, testing changes to an exist- ing system, and so forth. I’m not sug- gesting we should stop building them. But they also have problems.

l Heji ~ro@#~e.i take too long to budd andchange. Even with high-level tools, a fully functional prototype can take weeks to create. I have seen teams build a complete working lo-Ii proto- type in four hours. The goal is to get through as many iterations as you can during the design phase, because each iteration means improvement. If

testing flushes out problems with the basic metaphor or control structure in a design, changing the prototype can again take weeks. This is what Debbie Hix and Rex Hartson, re- searchers and faculty members at Virginia Tech, call the “Software de- veloper’s dilemma.” You can’t evalu- ate an interaction design until after it is built, but after building, changes t” the design are difficult.

Paper prototypes, on the other hand, are extremely fast to develop and the technique is very easy to learn. It is the fastest of the so-called

rapid prototyping techniques. To make a broad generalization, inter- face designers spend 95% of their time thinking about the design and anly 5% thinking about the mechan- ics of thr t”“l. Software-based tools, no matter how well executed, rcversc this ratio. l Reuiewm and L&en lend lo commcnl on “f;l nndfin~~h”rsua You are trying m get feedback on the big things: the flow of the conversation, the general

layout of the controls, the terminol- ogy, the expressiveness and power of the basic metaphor. With a slick soft- ware prototype, you are just as likely t” hear criticisms about your choice of fonts, color combinations, and button sires. On the back side of the same coin, developers easily become ob- sessed with the prettiness-power of a good tool, and spend their hours

choosing colors instead of coming up with new ideas.

In contrast, the hand-made ap- pearance of a paper or acetate proto- type forces users to think about con- tent rather than appearance. l Developers resist changes. They are attached t” their work because it was so hard to implement. Spend enough time crafting something and you are likely to fall in love with it. Knowing

this, team members may feel reluc- tant t” suggest that their colleague should make drastic changes to the lovely looking, weeks-in-the-making software prototype. They would bc less hesitant to suggest redrawing a sketch that took an hour to create. . A @,tot@e in software can .sel e$mLa- lions thrill wzll be hard to change. Proto- typing tools let you do wonderful things in a (relatively) short time. You can make something that looks like a finished product, fooling testers and even management into thinking how far you are along. If it tests well, you may wind up spending time on “re- verse damage control,” handling questions about your sudden lack of

progress. l A single bug in a hi-/i protolype fun bring a lest lo n comfilele halt. To test effectively, your prototype needs to be complete and robust enough for some- one TV try to do something useful with it. Even with the coolest of high- level tools, building a prototype is still essentially a programming exercise- and we all know how hard it can he t” get all the bugs out of a program. On the other hand, 1 often see teams cor-

recting “hugs” in a paper prototype while the test is in progress.

A Trojan Meme The spread of lo-6 design through my current project started with a visit from Jared Spool (with User Inter- face Engineering in Andover, Mass.). He and his associate presented the basic ideas, then put us to work in four trams to design and build a pro- totype of an automated menu for a

fast food restaurant. For three hours we discussed, designed, sketched and glued, then ran the results in a face- off competition with “real users” and a “real task.” That is, we brought people in from elsewhere in the building and told them, “you have $4.92. Order as much food as you can.” The designs were measured by

how quickly and efficiently people

Lo-fi prototyping works because it effectively educates developers to have a concern for usability and formative evalu- ation, and because it maximizes the number of times you get to

refine your design before you must commit to code.

could use the interfaces without coaching from the designers. Be- tween tests, each team had a few min- utes to refine their interface.

We were all impressed with the re- suits of the exercise. In about six hours we had learned the technique, designed an interface and built a model of it, conducted tests, and measurably improved the original design. That was four months ago, and now we have scores of people working on lo-ti designs, refining them through repeated tests with ac- tual “sers. Interface sketches are lying all over the place, scans are put on the network for peer review, and terms like “affordance” and “mental model” are common parlance.

I call this a “Trojan meme” instead ofjust a “selfish mcme” because it did more than reproduce itself through the department. (A meme is an idea- the mental equivalent of a gene, and selfish ones try to replicate them- selves in as many minds as possible.) As it spread, it served as a vehicle for spreading a general appreciation of the value of usability design: develop- ers saw first-hand the difference in people’s reactions to successive re- finements in their designs. Within days of designing an interface, they saw exactly how their work was per- ceived by people just like those who will eventually be using their prod- uct. The value of two important laws of interaction design was memorably demonstrated: “Know Your User,” and “You Aren’t Your User.”

Testing for iterative refinement is known in the interface design com- munity as “formative evaluation,” meaning you are evaluating your de- sign while it is still in its formative stages. Testing is used as a kind of natural selection for ideas, helping your design evolve toward a form that will survive in the wilds of the user community. This is in contrast to “summary evaluation,” which is done

once after the product is complete. With summary evaluation you find out how well you did, but you find out too late to make substantial changes.

Lo-ii prototyping works because it effectivelv educates dewlowers to have a Concern for usability and formative evaluation, and because it maximizes the number of times you get to refine your design before you must commit to code. To make the most of these advantages, the proto- typing effort needs to be carefully planned and followed by adequate testing and evaluation. (It also helps to have someone who can enthusias- tically champion the idea.) Hix and Hartson have an excellent chapter on formative evaluation in their book, Develofing User Interfam If you plan to adopt any of these techniques, I recommend you read their book.

The rest of this is drawn from our experience over dozens of designs and scores of tests, notes from Jared Spool’s workshop, and Hix and Hartson’s book.

Building a Lo-F1 Prototype I. Assemble a kit. In this decadent age of too many computers and too few paint brushes, it might be hard to get all the materials you need by rum- maging through the supply closet in the copy room. Make a trip to the of- fice supply store, or better yet, the art supply store, and buy enough school supplies to excite the creative im- pulses of your team. Here’s a shop- ping list:

l White, unlined, heavy paper that is bigger than letter size (11 by I7 inches is nice), and heavy enough to endure the rigors of repeated testing and revision. l Hundreds of 5-by-&inch cards. These come in handy as construction material, and later you’ll use them by the score for note taking during tests.

l Various adhesives. Tape: clear, col- ored, double-backed, pin stripin tape, whatever. Glue sticks, and most importantly, Post-It glue-a stick of the kind of glue that’s on the back of those sticky yellow notes. Rolls of white correction tape arc great for button labels and hurriedly written field contents. l Various markers-colored pens and pencils, highlighters, tine and thick markers, pastels. l Lots of sticky note pads of various sires and colors. l Acetate sheets--the kind you USC IO make overhead presentations. Hix and Hartson swear by these as the primary construction material for lo-ii interfaces. l See what you find in the architrc- ture section. They have sheets of rub- on texture, for example, which could give you an instant shading pattern. l Scissors, X-act” knives, straight- edges, Band-Aids.

Just like kindergartners, lo-6 dr- signers sometimes find inspiration in the materials at hand. So go ahead- buy that package of colored construct tion paper. The worst that can hap- pen is you won’t USC it. Eventually your tram will develop their own con- struction methods, and settle on a list of essentials for their lo-ii construction kit. 2. Set a deadline. There is a terrific temptation to think long and hard about each aspect of the interface be- fore you commit anything to paper. How should you arrange the menus? What should be in a dialog box, what should be in menus, and what should be in a tool palette? When you are faced with a blank sheet of paper, these kinds of decisions crowd your thoughts all at once. “Wait,” you think, ?ve haven’t thought about this enough!”

That’s exactly the point: no matter how hard you think about it, you

Ciawe I. Afewcomponents Of a paper prototvpe. The main window is in the mid- dle, showing a few Pieces of data added with strips Of Correction tape. and controls stuck on with Post-It paper. The window is sur- rounded by POP-UP menus, dia- log boxes, and sundry interface widgets.

gets, producing large amo”“ts of data, or rendering artistic and attrac- tive designs. Exploit these talenu and divide the labor accordingly.

Construct a first version com- pletely by hand. Sketch the widgets, hand-letter the labels. Don’t eve” worry about “sing a straightedge at first. Just get the ideas down on paper. Test small details on one an- other, or drag people in from the hall for quick tests of alternative solutions.

Of course, hand-draw” sketches, no matter bow carefully done, may not be appropriate for some testing situations. For example, a customer may be willing to let you test your design with actual users. They may understand the transience of the pro- totype, but you still want to make a good impression. You want to look sharp.

Some of the teams on my project have made remarkably attractive paper interfaces using components created with drawing software, then printed on a laser printer. Some of them build up a familiar look with elements taken from screen captures. To facilitate this kind of thing, they set up a library of lo-ti widget images: blank buttons of all sizes, window and dialog frames, scroll bars, entry tields, and so on. People print these out, re- size them on the photocopier, and make them part of their standard lo-t7 kit. Or they resize them on the com- puter, add labels, and print o”t a cm- tom part for their work in progress.

This is a” example of the kind of

preparation that will help lo-ii proto- typing become a normal part of your design process. Preparing a widget library, writing down guidelines, and taking time to train people will make everyone more enthusiastic and productive.

Preparing for a Test However much care you take in building your prototype, the tests will be ineffective unless you prepare well for them. Be sure to attend to the fol- lowing matters.

1. Select your trsers. Before you start designing, you should do enough user and task analysis to understand the people who will he using your software--their educational and training background, knowledge of computers, their familiarity with the domain, typical tasks involved in their job, and so on. Based on this study, you can look for pools of po- tential testers for your prototype. With a good user profile on band, you can develop a questionnaire that will help to choose the best represen- tative users from available candidates.

If would seem reasonable to ar- range it so the people testing your prototype are the same people who will be using the final product. But bona fide members of the user com- munity may be hard to corral for the time it takes to run a test, and using them may not be the best idea in the long run. Be sensitive to the political climate. People may feel threatened

by the intrusion of a new system into their work (perhaps justifiably!), or there may be a competitive situation that makes your employer reluctant to expose “ew ideas outside the walls of your building.

Since you are looking for appro- priate knowledge and skills, not job titles, you can often get by with “sur- rogate users”-people who fit the same profile as your actual clients, but free from whatever association that prevents you from testing with the clients themselves. I’ve heard of all kinds of tricks for attracting peo- ple to the test. Spool says he’s done everything from running ads in the newspaper to recruiting university students to contacting local user groups. Anything to avoid using ac- tual customers, employees, or friends and family. (The latter may be acces- sible, but there are a lot of things about sharing ties in the same social web that can conspire to damage a usability test. For example, testers who know you or the project may skew the results by trying hard to please you or do what they think you expect them to do.)

Finally, remember that no two people are the same, and your prod- uct’s users may be a diverse group. Try to recruit testers that represent the whole range of characteristics in your target audience. Our practice has been to conduct at least one

elgure2. A lo-fl testing session

. . .e _.. bb

mund of resting in our off& with surrogates, then go t” the field fog testing with the m”st typical end users we can find. 2. Prepare test scenarios. Write a set of scenarios, preferably drawn fl-om task analysis, describing the product during use in a typical work situati”n. Design your prototype to support a few of these scenarios, narrowing the scope of your &orts f” a reasonably small set of functions, but broad enough t” allow meaningful tests.

If possible, ask someone t” review the scenarios and sample data and tell you whether they look realistic. In our experience, people find a lo-fi interface more engaging-more real- istic-if it shows data that looks famil- iar and we ask them t” perform real- istic tasks. This helps draw them into the “let’s pretend you’re really using a cnmputer at your job” world, which leads to better tests. On the other hand, unrealistic scenari”s and data can severely damage the credibility of your design. 3. Practice. Just as a bug in a soft- ware prototype can ruin a test se,- sion, so can a bug in a lo-fi prototype. That bug could be a missing compw “em, a misunderstanding “n the pan “f the person playing “computer,” “I even excessive hesitation and c”nf& Sian because the team is unfamiliar- with how to conduct a tat. So to avoid embarrassment, conduct xv- eral dry runs belore you test with people from outside your team. Each team member should be comfortable with his or her role, and you need I” make SUE you have the supplies and equipment needed TV gather gaod information.

Conducting a Test We find it takes four pcoplc t” get tbr mat “ut of a test session (see Figure 2). and that their activities fall int” four essential roles:

l Greeler. Much the same as the usher in a church, thr greeter welc”mes users and tries t” put them at ease. We have some forms we ask people t” lill out-an experience profile, for example--a job the greeter handles while other team members are setting up for the test. l Facililnlor. Once the test is set up, the facilitator takes the lead, and is

Practical Progmmmer _L. ~__ -w.. ..-.

the only team member who is allowed to speak freely during the test. Facili- tating means three things: giving the user instructions, encouraging the user t” express his or her thoughts during the test, and making sure ev- crything gets donr on time. This is a difficult enough job that the facili- tat”r should not be expected t” take notes during a session. l Compulw. One tram member acts as the “computer.” He or she knows the application I”gic thowughly, and sus- tains the illusion that the paper pi”- totype behaves similar to a real com- puter (with an unusually slow response time). A pointing fingel- serves as a cursor, and expressions like, “I ‘YP’ ‘half-silvered bicuspidon in that field” substitute for keyboard entry. If the use,. touches a control, the computer in- ranges the prototype t” simulate the response, taking care not t” explain anything other than the bebavi”~- of the interface. l Obsuwrs. The rest of the tram members quietly take notes “n s-by- X-inch index cards, writing one ob- servation prr card. If they think “1 a recommended solwi”n, they write it on the same card that record, the problem.

Since all of these r”les can be ex- hausting, we rotate them among the tram when we amduct more than OFF session a day (and we very “lien schedule low sessions in a day).

Typical tat sessions usually last a little wee- an haul-, and go through three phases: getting ready, conduct- ing the test, and debriefing. We begin with greetings, introductiwr. ire- frrshmrnts and general ire-bl-eaking, trying our very best to assuw people that the test is confidenti the results will remain anonymous, and their supervisor won’t hear a w”rd about whether or not they “got it.” people often say things like, “Am I flunking the test? Am I getting it right?” To which we anwet-, “Don’t worry, the qurstion is whether or not we are flunking. The interface is on trial, not you. If you fail t” understand some- thing or can’t complete one of the tasks, that’s a sign of trouble with the design, not a lack of intelligence on your part.”

While this is going “n, someone positkms a video camera (we tape all

the sessions) so it points down over the user’s shoulder t” lo”k at the in- terface and the hands moving over it. No ““e’s face ever appears on tape.

During the test, the Facilitator hands written tasks t” the user one at a time. These must be very clear and detailed. As the person works on each task, the facilitator tries t” elicit the user’s thr,ughts without influencing his or her choicer. “What are you thinking right now?” “What quca- ti”ns are “n your mind?” “Are you confused about what you’re seeing?”

While this is going on, the rest of the tram members “bsrrve and take notes, and may occasionally interject a question. But they must never laugh, gape, say “a-ha.” nudge one another, “r “then-wise display their reaction to what’s happening to their careful design. This kind of thing can intimidate or humiliate users. ruining the arlationship and spoiling the test. It can be terribly difficult to keep still while the user spends IO minutea using all the wrong conools for all the wnmg reasons. You will feel a com- pelling urge to explain the de+ t” your users. Don’t give in.

When the hour is over, we spend a IO-minute debriefing session asking questions, gathering imp,-essions, and expressing our thanks.

Evaluating ReSultS I.“-fi “1 hi-Ii, prrnotyping is worthleas unless information is gathered and the product is relined based on you) findings. As I wr”te earlier, Hix and Harts”” nicety cover the details of gathering and analyzing trst data. We spend quite a bit of time (at least a day per iteration) sorting and priori- tizing the n”tr cards we wr”tr during the test sessions. Ow methr,d in- volves arranging the paper prototype “n a big table. then piling the n”tc cards next t” its relevant interface component. Then team members divide the labor ofgoing through the piles t” summarize and prioritize rhc problems.

These sorted piles inform a written report on findings from the test, and form the agrnda of a merting t” dis- cuss recommended changes f” the design. The team warks through the piles and agrees “n suggested changes, which are written on Post-It n”tes and affixed directly to the rele-

,... L _. ,.. . . . . . LL _.b. >

van, part of the paper prototype. Constructing the revised prototype becomes a procrss of taking each component, and following the recom- mendations that were stuck to it.

Hix, who for years has been teaching courses and workshops in interface design, says that people consistently enter the tint lo-f, exercise with skep- ticism. After trying it they invariably say something to the extent of, “I can’t believe how much we learned from this!” If this column is the first place you have heard about the lo4 technique, one danger is that you will set aside this magazine with just enough skepticism that, however much interest I’ve managed to create, you will fail to actually try it.

Having seen other skeptics con- verted, I’m confident in recommend- ing this technique. If you already have a working high-fidelity proto- type, it probably isn’t worth abandon- ing that course to switch to lo-L But if you are in the very early stages of de- sign and exploring broad questions, or if you need to learn more now, lo-fi prototyping is just the tool to pick up. 0

Ku&l, J. and knee. s. Twn,y-two ups for a happier, healthirr prototype. lnlerar.

I, I “a”. ,994). 35-4”.

jerrs ranging fiiom the basic meLa- Now considrr a diffcrrnt situation, phor to the choice of background one I have witnessed first-hand over color. The team .just barely has time the past few months: a development to incorporatr these comments into a team spends weeks designing an in- rwiscd design brforr committing terface. During the first few days,

they construct a paper prototype of their initial thinking about all aspects of the design, and test it with typical

by Marc Rettig representatives of the user commu-

nity. One of them “plays computer,” moving components of the paper in- terface around on the table in re- sponse to the users’ actions. The oth-

ers observe and take notes. After the tests they take a week to distill lessons from their observations, redesign the interface, and retest with several new users. This process continues until, at the end of the time allotted for inter- face design, the team has revised their design four times and tested it with many typical users.

This technique-building proto-

types on paper and testing them with real users-is called low-fidelity pro- totyping or “lo-t7 for short. The value of promtyping is widely recog- nized, but as thr first situation exenl- plilies, that value is not always gained in practice. If that has brrn your ex- perience, you might want t” try lo-C promtyping, which requires little more in the way of implementation skills than the ones you learned in kindergarten.

The idea oflo-fi prototyping (a.k.a. “paper prototypes”) has been around a long time. So long, in fact, that nmre than one person in the CHI community expressed surprise when I said I was planning to write a col- umn on the subject. But I see this as a wonderfully simple and effective tool

that has somehow failed to come int” general use in the software commu- nity. I say this based on the success of the teams I’ve watched over the past several months together with the fact that this is the first commercial proj- ect where I’ve seen paper prototypes employed.

Paper prototyping is potentially a breakthrough idea for organizations that have never tried it, since it allows you to demonstrate the behavior of

an interface very early in develop- ment, and test designs with real users. If quality is partially a function of the number of iterations and reftnements a design undergoes before it hits the street, lo-fi prototyping is a technique ,that can dramatically increase quality. It is fast, it brings results early in de- velopment (when it is relatively cheap

to make changes), and allows a team to try far more ideas than they could with high-fidelity prototypes. Lo-fi prototyping helps you apply Fudd’s first law of creativity: “To get a good idra, grt lots of ideas.”

The Problems with Hi-Fi For years developers have used ev- erything from demo-builders to mul-

timedia tools to high-level languages to build prototypes. Lo-fi proponents call these “hi-h prototypes.” They have their place: selling an idea, test- ing look-and-feel, detailed proof-of- concept, testing changes to an exist- ing system, and so forth. I’m not sug- gesting we should stop building them. But they also have problems.

l Heji ~ro@#~e.i take too long to budd andchange. Even with high-level tools, a fully functional prototype can take weeks to create. I have seen teams build a complete working lo-Ii proto- type in four hours. The goal is to get through as many iterations as you can during the design phase, because each iteration means improvement. If

testing flushes out problems with the basic metaphor or control structure in a design, changing the prototype can again take weeks. This is what Debbie Hix and Rex Hartson, re- searchers and faculty members at Virginia Tech, call the “Software de- veloper’s dilemma.” You can’t evalu- ate an interaction design until after it is built, but after building, changes t” the design are difficult.

Paper prototypes, on the other hand, are extremely fast to develop and the technique is very easy to learn. It is the fastest of the so-called

rapid prototyping techniques. To make a broad generalization, inter- face designers spend 95% of their time thinking about the design and anly 5% thinking about the mechan- ics of thr t”“l. Software-based tools, no matter how well executed, rcversc this ratio. l Reuiewm and L&en lend lo commcnl on “f;l nndfin~~h”rsua You are trying m get feedback on the big things: the flow of the conversation, the general

layout of the controls, the terminol- ogy, the expressiveness and power of the basic metaphor. With a slick soft- ware prototype, you are just as likely t” hear criticisms about your choice of fonts, color combinations, and button sires. On the back side of the same coin, developers easily become ob- sessed with the prettiness-power of a good tool, and spend their hours

choosing colors instead of coming up with new ideas.

In contrast, the hand-made ap- pearance of a paper or acetate proto- type forces users to think about con- tent rather than appearance. l Developers resist changes. They are attached t” their work because it was so hard to implement. Spend enough time crafting something and you are likely to fall in love with it. Knowing

this, team members may feel reluc- tant t” suggest that their colleague should make drastic changes to the lovely looking, weeks-in-the-making software prototype. They would bc less hesitant to suggest redrawing a sketch that took an hour to create. . A @,tot@e in software can .sel e$mLa- lions thrill wzll be hard to change. Proto- typing tools let you do wonderful things in a (relatively) short time. You can make something that looks like a finished product, fooling testers and even management into thinking how far you are along. If it tests well, you may wind up spending time on “re- verse damage control,” handling questions about your sudden lack of

progress. l A single bug in a hi-/i protolype fun bring a lest lo n comfilele halt. To test effectively, your prototype needs to be complete and robust enough for some- one TV try to do something useful with it. Even with the coolest of high- level tools, building a prototype is still essentially a programming exercise- and we all know how hard it can he t” get all the bugs out of a program. On the other hand, 1 often see teams cor-

recting “hugs” in a paper prototype while the test is in progress.

A Trojan Meme The spread of lo-6 design through my current project started with a visit from Jared Spool (with User Inter- face Engineering in Andover, Mass.). He and his associate presented the basic ideas, then put us to work in four trams to design and build a pro- totype of an automated menu for a

fast food restaurant. For three hours we discussed, designed, sketched and glued, then ran the results in a face- off competition with “real users” and a “real task.” That is, we brought people in from elsewhere in the building and told them, “you have $4.92. Order as much food as you can.” The designs were measured by

how quickly and efficiently people

Lo-fi prototyping works because it effectively educates developers to have a concern for usability and formative evalu- ation, and because it maximizes the number of times you get to

refine your design before you must commit to code.

could use the interfaces without coaching from the designers. Be- tween tests, each team had a few min- utes to refine their interface.

We were all impressed with the re- suits of the exercise. In about six hours we had learned the technique, designed an interface and built a model of it, conducted tests, and measurably improved the original design. That was four months ago, and now we have scores of people working on lo-ti designs, refining them through repeated tests with ac- tual “sers. Interface sketches are lying all over the place, scans are put on the network for peer review, and terms like “affordance” and “mental model” are common parlance.

I call this a “Trojan meme” instead ofjust a “selfish mcme” because it did more than reproduce itself through the department. (A meme is an idea- the mental equivalent of a gene, and selfish ones try to replicate them- selves in as many minds as possible.) As it spread, it served as a vehicle for spreading a general appreciation of the value of usability design: develop- ers saw first-hand the difference in people’s reactions to successive re- finements in their designs. Within days of designing an interface, they saw exactly how their work was per- ceived by people just like those who will eventually be using their prod- uct. The value of two important laws of interaction design was memorably demonstrated: “Know Your User,” and “You Aren’t Your User.”

Testing for iterative refinement is known in the interface design com- munity as “formative evaluation,” meaning you are evaluating your de- sign while it is still in its formative stages. Testing is used as a kind of natural selection for ideas, helping your design evolve toward a form that will survive in the wilds of the user community. This is in contrast to “summary evaluation,” which is done

once after the product is complete. With summary evaluation you find out how well you did, but you find out too late to make substantial changes.

Lo-ii prototyping works because it effectivelv educates dewlowers to have a Concern for usability and formative evaluation, and because it maximizes the number of times you get to refine your design before you must commit to code. To make the most of these advantages, the proto- typing effort needs to be carefully planned and followed by adequate testing and evaluation. (It also helps to have someone who can enthusias- tically champion the idea.) Hix and Hartson have an excellent chapter on formative evaluation in their book, Develofing User Interfam If you plan to adopt any of these techniques, I recommend you read their book.

The rest of this is drawn from our experience over dozens of designs and scores of tests, notes from Jared Spool’s workshop, and Hix and Hartson’s book.

Building a Lo-F1 Prototype I. Assemble a kit. In this decadent age of too many computers and too few paint brushes, it might be hard to get all the materials you need by rum- maging through the supply closet in the copy room. Make a trip to the of- fice supply store, or better yet, the art supply store, and buy enough school supplies to excite the creative im- pulses of your team. Here’s a shop- ping list:

l White, unlined, heavy paper that is bigger than letter size (11 by I7 inches is nice), and heavy enough to endure the rigors of repeated testing and revision. l Hundreds of 5-by-&inch cards. These come in handy as construction material, and later you’ll use them by the score for note taking during tests.

l Various adhesives. Tape: clear, col- ored, double-backed, pin stripin tape, whatever. Glue sticks, and most importantly, Post-It glue-a stick of the kind of glue that’s on the back of those sticky yellow notes. Rolls of white correction tape arc great for button labels and hurriedly written field contents. l Various markers-colored pens and pencils, highlighters, tine and thick markers, pastels. l Lots of sticky note pads of various sires and colors. l Acetate sheets--the kind you USC IO make overhead presentations. Hix and Hartson swear by these as the primary construction material for lo-ii interfaces. l See what you find in the architrc- ture section. They have sheets of rub- on texture, for example, which could give you an instant shading pattern. l Scissors, X-act” knives, straight- edges, Band-Aids.

Just like kindergartners, lo-6 dr- signers sometimes find inspiration in the materials at hand. So go ahead- buy that package of colored construct tion paper. The worst that can hap- pen is you won’t USC it. Eventually your tram will develop their own con- struction methods, and settle on a list of essentials for their lo-ii construction kit. 2. Set a deadline. There is a terrific temptation to think long and hard about each aspect of the interface be- fore you commit anything to paper. How should you arrange the menus? What should be in a dialog box, what should be in menus, and what should be in a tool palette? When you are faced with a blank sheet of paper, these kinds of decisions crowd your thoughts all at once. “Wait,” you think, ?ve haven’t thought about this enough!”

That’s exactly the point: no matter how hard you think about it, you

Ciawe I. Afewcomponents Of a paper prototvpe. The main window is in the mid- dle, showing a few Pieces of data added with strips Of Correction tape. and controls stuck on with Post-It paper. The window is sur- rounded by POP-UP menus, dia- log boxes, and sundry interface widgets.

gets, producing large amo”“ts of data, or rendering artistic and attrac- tive designs. Exploit these talenu and divide the labor accordingly.

Construct a first version com- pletely by hand. Sketch the widgets, hand-letter the labels. Don’t eve” worry about “sing a straightedge at first. Just get the ideas down on paper. Test small details on one an- other, or drag people in from the hall for quick tests of alternative solutions.

Of course, hand-draw” sketches, no matter bow carefully done, may not be appropriate for some testing situations. For example, a customer may be willing to let you test your design with actual users. They may understand the transience of the pro- totype, but you still want to make a good impression. You want to look sharp.

Some of the teams on my project have made remarkably attractive paper interfaces using components created with drawing software, then printed on a laser printer. Some of them build up a familiar look with elements taken from screen captures. To facilitate this kind of thing, they set up a library of lo-ti widget images: blank buttons of all sizes, window and dialog frames, scroll bars, entry tields, and so on. People print these out, re- size them on the photocopier, and make them part of their standard lo-t7 kit. Or they resize them on the com- puter, add labels, and print o”t a cm- tom part for their work in progress.

This is a” example of the kind of

preparation that will help lo-ii proto- typing become a normal part of your design process. Preparing a widget library, writing down guidelines, and taking time to train people will make everyone more enthusiastic and productive.

Preparing for a Test However much care you take in building your prototype, the tests will be ineffective unless you prepare well for them. Be sure to attend to the fol- lowing matters.

1. Select your trsers. Before you start designing, you should do enough user and task analysis to understand the people who will he using your software--their educational and training background, knowledge of computers, their familiarity with the domain, typical tasks involved in their job, and so on. Based on this study, you can look for pools of po- tential testers for your prototype. With a good user profile on band, you can develop a questionnaire that will help to choose the best represen- tative users from available candidates.

If would seem reasonable to ar- range it so the people testing your prototype are the same people who will be using the final product. But bona fide members of the user com- munity may be hard to corral for the time it takes to run a test, and using them may not be the best idea in the long run. Be sensitive to the political climate. People may feel threatened

by the intrusion of a new system into their work (perhaps justifiably!), or there may be a competitive situation that makes your employer reluctant to expose “ew ideas outside the walls of your building.

Since you are looking for appro- priate knowledge and skills, not job titles, you can often get by with “sur- rogate users”-people who fit the same profile as your actual clients, but free from whatever association that prevents you from testing with the clients themselves. I’ve heard of all kinds of tricks for attracting peo- ple to the test. Spool says he’s done everything from running ads in the newspaper to recruiting university students to contacting local user groups. Anything to avoid using ac- tual customers, employees, or friends and family. (The latter may be acces- sible, but there are a lot of things about sharing ties in the same social web that can conspire to damage a usability test. For example, testers who know you or the project may skew the results by trying hard to please you or do what they think you expect them to do.)

Finally, remember that no two people are the same, and your prod- uct’s users may be a diverse group. Try to recruit testers that represent the whole range of characteristics in your target audience. Our practice has been to conduct at least one

elgure2. A lo-fl testing session

. . .e _.. bb

mund of resting in our off& with surrogates, then go t” the field fog testing with the m”st typical end users we can find. 2. Prepare test scenarios. Write a set of scenarios, preferably drawn fl-om task analysis, describing the product during use in a typical work situati”n. Design your prototype to support a few of these scenarios, narrowing the scope of your &orts f” a reasonably small set of functions, but broad enough t” allow meaningful tests.

If possible, ask someone t” review the scenarios and sample data and tell you whether they look realistic. In our experience, people find a lo-fi interface more engaging-more real- istic-if it shows data that looks famil- iar and we ask them t” perform real- istic tasks. This helps draw them into the “let’s pretend you’re really using a cnmputer at your job” world, which leads to better tests. On the other hand, unrealistic scenari”s and data can severely damage the credibility of your design. 3. Practice. Just as a bug in a soft- ware prototype can ruin a test se,- sion, so can a bug in a lo-fi prototype. That bug could be a missing compw “em, a misunderstanding “n the pan “f the person playing “computer,” “I even excessive hesitation and c”nf& Sian because the team is unfamiliar- with how to conduct a tat. So to avoid embarrassment, conduct xv- eral dry runs belore you test with people from outside your team. Each team member should be comfortable with his or her role, and you need I” make SUE you have the supplies and equipment needed TV gather gaod information.

Conducting a Test We find it takes four pcoplc t” get tbr mat “ut of a test session (see Figure 2). and that their activities fall int” four essential roles:

l Greeler. Much the same as the usher in a church, thr greeter welc”mes users and tries t” put them at ease. We have some forms we ask people t” lill out-an experience profile, for example--a job the greeter handles while other team members are setting up for the test. l Facililnlor. Once the test is set up, the facilitator takes the lead, and is

Practical Progmmmer _L. ~__ -w.. ..-.

the only team member who is allowed to speak freely during the test. Facili- tating means three things: giving the user instructions, encouraging the user t” express his or her thoughts during the test, and making sure ev- crything gets donr on time. This is a difficult enough job that the facili- tat”r should not be expected t” take notes during a session. l Compulw. One tram member acts as the “computer.” He or she knows the application I”gic thowughly, and sus- tains the illusion that the paper pi”- totype behaves similar to a real com- puter (with an unusually slow response time). A pointing fingel- serves as a cursor, and expressions like, “I ‘YP’ ‘half-silvered bicuspidon in that field” substitute for keyboard entry. If the use,. touches a control, the computer in- ranges the prototype t” simulate the response, taking care not t” explain anything other than the bebavi”~- of the interface. l Obsuwrs. The rest of the tram members quietly take notes “n s-by- X-inch index cards, writing one ob- servation prr card. If they think “1 a recommended solwi”n, they write it on the same card that record, the problem.

Since all of these r”les can be ex- hausting, we rotate them among the tram when we amduct more than OFF session a day (and we very “lien schedule low sessions in a day).

Typical tat sessions usually last a little wee- an haul-, and go through three phases: getting ready, conduct- ing the test, and debriefing. We begin with greetings, introductiwr. ire- frrshmrnts and general ire-bl-eaking, trying our very best to assuw people that the test is confidenti the results will remain anonymous, and their supervisor won’t hear a w”rd about whether or not they “got it.” people often say things like, “Am I flunking the test? Am I getting it right?” To which we anwet-, “Don’t worry, the qurstion is whether or not we are flunking. The interface is on trial, not you. If you fail t” understand some- thing or can’t complete one of the tasks, that’s a sign of trouble with the design, not a lack of intelligence on your part.”

While this is going “n, someone positkms a video camera (we tape all

the sessions) so it points down over the user’s shoulder t” lo”k at the in- terface and the hands moving over it. No ““e’s face ever appears on tape.

During the test, the Facilitator hands written tasks t” the user one at a time. These must be very clear and detailed. As the person works on each task, the facilitator tries t” elicit the user’s thr,ughts without influencing his or her choicer. “What are you thinking right now?” “What quca- ti”ns are “n your mind?” “Are you confused about what you’re seeing?”

While this is going on, the rest of the tram members “bsrrve and take notes, and may occasionally interject a question. But they must never laugh, gape, say “a-ha.” nudge one another, “r “then-wise display their reaction to what’s happening to their careful design. This kind of thing can intimidate or humiliate users. ruining the arlationship and spoiling the test. It can be terribly difficult to keep still while the user spends IO minutea using all the wrong conools for all the wnmg reasons. You will feel a com- pelling urge to explain the de+ t” your users. Don’t give in.

When the hour is over, we spend a IO-minute debriefing session asking questions, gathering imp,-essions, and expressing our thanks.

Evaluating ReSultS I.“-fi “1 hi-Ii, prrnotyping is worthleas unless information is gathered and the product is relined based on you) findings. As I wr”te earlier, Hix and Harts”” nicety cover the details of gathering and analyzing trst data. We spend quite a bit of time (at least a day per iteration) sorting and priori- tizing the n”tr cards we wr”tr during the test sessions. Ow methr,d in- volves arranging the paper prototype “n a big table. then piling the n”tc cards next t” its relevant interface component. Then team members divide the labor ofgoing through the piles t” summarize and prioritize rhc problems.

These sorted piles inform a written report on findings from the test, and form the agrnda of a merting t” dis- cuss recommended changes f” the design. The team warks through the piles and agrees “n suggested changes, which are written on Post-It n”tes and affixed directly to the rele-

,... L _. ,.. . . . . . LL _.b. >

van, part of the paper prototype. Constructing the revised prototype becomes a procrss of taking each component, and following the recom- mendations that were stuck to it.

Hix, who for years has been teaching courses and workshops in interface design, says that people consistently enter the tint lo-f, exercise with skep- ticism. After trying it they invariably say something to the extent of, “I can’t believe how much we learned from this!” If this column is the first place you have heard about the lo4 technique, one danger is that you will set aside this magazine with just enough skepticism that, however much interest I’ve managed to create, you will fail to actually try it.

Having seen other skeptics con- verted, I’m confident in recommend- ing this technique. If you already have a working high-fidelity proto- type, it probably isn’t worth abandon- ing that course to switch to lo-L But if you are in the very early stages of de- sign and exploring broad questions, or if you need to learn more now, lo-fi prototyping is just the tool to pick up. 0

Ku&l, J. and knee. s. Twn,y-two ups for a happier, healthirr prototype. lnlerar.

I, I “a”. ,994). 35-4”.