Chapter 4: Eight Guiding Principles

Prototyping isn’t as hard as you think. In fact, it’s pretty easy. Anyone can prototype. Just like anything else, the more you do it, the easier it gets. ^nBut here’s the catch—it’s just as easy to mess it up.

Most of the mistakes I’ve made, seen, or heard about didn’t happen from selecting the wrong tool or method. Instead, most of the mistakes came from the following situations:

• Prototyping either too much or too little.
• Prototyping the wrong thing.
• Not setting expectations for what the prototype will be.

Effective prototyping is about finding balance and setting expectations. In this chapter, I’m going to reveal eight guiding principles I’ve developed for more effective prototyping. These principles apply, regardless of method or tool.

Best of all, whether you’re a seasoned prototyper or just getting your feet wet, you’ll benefit from the following eight guiding principles.

Principle 1: Understand Your Audience and Intent

This is the first and by far the most critical principle in the prototyping process. Understanding your audience for and the intent of the prototype drives every other aspect of the prototyping process. After you understand your audience and intent, you will be better equipped to:

• Determine what you need to prototype.
• Set appropriate expectations.
• Determine the right level of fidelity.
• Pick the right tool for the job.

Let’s begin with addressing the question of audience, since it all starts here. When you understand who the audience is, you can determine what you need to prototype, how much you need to prototype, and what fidelity is appropriate for them.

If the audience is myself, another designer, or even an engineer, then a lo-fi paper prototype or a quick-and-dirty PowerPoint or HTML simulation is probably good enough. Those are mediums you can work with, you can understand, and that will get your point across without too much work.

However, if the audience for your prototype is a customer or a senior executive, chances are you’ll need something more polished. A cocktail napkin sketch probably won’t cut it.

When considering your audience, you should consider what medium or level of fidelity they will be comfortable with. If they can work with a few rough sketches on paper and you’re confident that is all you need to communicate your concept to them, then go for it. If, on the other hand, your audience is going to struggle with that medium and you’re going to struggle using it to communicate your concept to them, then pick a different medium or fidelity.

Once you understand your audience and the intent of your objective, you’re ready to begin your planning phase and start prototyping.

Principle 2: Plan a Little—Prototype the Rest

Software systems change constantly and quickly. By planning a little and prototyping the rest, you work incrementally and iteratively, making up for the ever-changing environment.

The more work you do in the planning process, the better off you’ll be. Of course, there is a point of diminishing return, so use some common sense.

I’m often asked how much planning should be done before you start prototyping. While there’s no magic number, I plan up to approximately 70 percent of the design through sketching and then it’s down to the business of prototyping.

Why 70 percent? There are two main reasons. First, since my goal is to get audience feedback, the faster I get it into their hands, the faster I can get feedback. Second, prototyping is a great tool for working through a design. If I can get 70 percent of my design concept down on paper, then I can use prototyping to work through the rest.

In some ways, this makes prototyping a leap of faith. For those who are used to a waterfall method, or an environment where everything is “planned to a T” before you begin, this will probably make you a little uncomfortable. But just try it. Try planning about 70 percent of your prototype on a whiteboard or with paper and pencil and then starting prototyping. I’m confident you’ll like the results.

Naturally, each prototype is created on a case-by-case basis. Sometimes, you might need to plan a little more, or you can plan a little less. Mission-critical systems, like a missile defense system or a system for monitoring a patient’s vital signs in a hospital, will probably take a little more planning than say a video player.

There are other factors you might need to consider, such as environment, the tools you’re using, and so on. Your magic number might not be 70 percent. Experiment a little with the amount of planning-to-prototyping you do. You’ll find your sweet spot after a few tries.

When you plan a little and prototype the rest, you’ll see the system come together quickly. You’ll find your mistakes fast—and yes, there will be mistakes. You’ll be able to fix those mistakes with less total time and effort. Best of all, you’ll have something your audience can play with and ultimately give you feedback on that you can use in a timely manner.

Principle 3: Set Expectations

Setting expectations is based on a psychological technique known as priming. When you prime your audience, you guide their attention and focus.

Let’s try a little experiment. I’ve prototyped a shopping cart and checkout experience for the ecommerce area of a mobile service provider. In just a minute, I’m going to show you a prototype of some of the concepts, which will highlight a few key features, such as featured products during the shopping experience and promoting phone accessories during the checkout process. Both of these key features will help increase profitability through add-on sales.

See how this works? I haven’t even shown you a prototype yet, but you have an expectation of what you’re going to see. You can even start to imagine them.

When I show you the prototype, you’re more likely to focus on looking for the featured product and promoted accessories than you are on what’s in the header and footer or what color the checkout button is.

Setting expectations typically boils down to two things: fidelity and functionality. For companies who are just starting to prototype, this is one of the most common mistakes and the easiest to avoid.

Remember the first guiding principle—know your audience and intent. If this is the first experience your audience has with prototyping, it’s critical you set their expectations of what to expect from the prototype. Reactions to a prototype are more favorable if the audience can predict with some degree of certainty what they will and won’t see.

By setting the expectation up-front, you avoid the rabbit-hole discussions about detailed interactions or pieces of functionality that simply haven’t been prototyped yet. Not to say that they won’t come up, because they will. By setting expectations correctly in the beginning, you give yourself an easy out—it’s not part of the prototype yet, but you can work it into the next release.

After you’ve primed your audience and set their expectations, launch the prototype and show them the demo. Don’t be afraid to discuss things that aren’t in the prototype at this stage, but try to keep the discussion focused on what is in this particular prototype. Remind them that this is a prototype and that some things might not be fully fleshed out yet.

Tip Create a Playlist Script

Write a short “playlist” of the most important features that you want to highlight when demo’ing your prototype. It will help keep you on track and ensure that you don’t miss anything during the presentation.

Principle 4: You Can Sketch

We’re so lo-fi it’s not even funny.

—Scott Matthews, Xplane

At a small conference named Overlap, David Gray of Xplane asked by a show of hands who could draw. Of the 40 plus people attending only a few raised their hands. Then Dave asked another question, “Who here could draw when they were a kid?” Everyone in the room raised their hands. His response was simple, “So, what happened between then and now that you lost your ability to draw?” Nobody really had a good response.

Dave, with some help from his colleague Scott Matthews, went on to show how you could draw anything you need with a few simple shapes—a square, a triangle, a circle, and a straight line. He showed how you could draw a person running similar to the sketch in Figure 4.1.

Figure 4.1 (Open in Flickr)

Sketch of a running man.

You probably won’t find that particular drawing in the next issue of any anatomy book, but we all get the picture. And that’s what prototypes are—showing, communicating, and helping your audience get the picture.

I don’t consider myself to be an artist, but I do sketch—a lot. Some of my sketches are more refined than others. Sometimes I’ll put actual words for field labels, and other times I’ll just draw lines to represent that a label needs to be there, as shown in Figure 4.2.

Figure 4.2 (Open in Flickr)

Sketch with lines for labels and text.

If I’m doing an ultra quick-and-dirty sketch, where I’m really only interested in carving out parts of the screen real estate for functionality, I’ll go lower fidelity and typically just use lines. Or if I’m live sketching with another designer or the client, I’ll use the same technique.

If the actual order of the fields is critical and I need to communicate that, I’ll go a little higher fidelity and either write the labels in or possibly open Illustrator and use it to sketch out the screen.

This decision often comes back to the first principle: Know your audience and intent. If it’s just me, I’m often fine with lines and boxes, no labels needed. (I’ll have a list of those written on a separate piece of paper.) If it’s someone else who’s consuming it, I’ll usually put in a little more effort and write out the labels.

Remember if you could draw when you were a kid, you can draw now. Your goal isn’t to create an illustration for the New Yorker, it’s to communicate your idea. After all, it’s just a prototype. Which brings us to Principle 5.

Tip Whiteboarding AJAX

Try using a whiteboard for sketching. You can simulate interactions and AJAX transitions through erasing and redrawing.

Principle 5: It’s a Prototype—Not the Mona Lisa

Prototypes by their very nature are somewhat incomplete, sketchy versions of the final product. They’re not perfect. They don’t have to be. They’re not meant to be. In fact, a slightly rough and sketchy prototype is often better for getting feedback.

If it’s unfinished, participants are more apt to give their feedback. They don’t feel that all the decisions have been made and are subsequently set in stone.

Admittedly, there are cases when you need something more refined. A sketchy prototype at a trade show probably isn’t going to cut it. And your CEO might have some trouble envisioning the final product from a sketch or a black-and-white version of the prototype. So, again, use some common sense judgment.

What I can tell you with great confidence, however, is this—in most cases, your prototype doesn’t have to be a Mona Lisa—good enough is good enough.

You’re not shooting for perfection here—it’s a prototype. You’re shooting for something that takes the least amount of time and effort required to communicate to your audience the core concept of your idea. All you need is the right level of fidelity. No more. No less.

Principle 6: If You Can’t Make It, Fake It

This is probably the biggest hurdle for newbies venturing into prototyping. Whenever I give a talk or workshop on prototyping, I start by asking the audience a few questions:

• How many people feel comfortable writing code (either HTML or something else)?
• How many people have prototyped in some way, shape, or form in the past (either PowerPoint, HTML, Dreamweaver, PDFs, etc.)?

In general, I find that the more designers there are in the room, the fewer people I find that feel comfortable writing code of some kind and the fewer people who have prototyped or feel comfortable prototyping. This typically comes down to the myth that if you can’t write code, you can’t prototype. And this has increased with RIAs. If you can’t write JavaScript, then you can’t prototype.

As prototyping gets quicker and easier, it really does save a lot of time to quickly prototype the ideas people have and show them in use. It fleshes out the wheat from the chaff very effectively.

—Baruch Sachs, Director, Human Factors Design and Pegasystems

If you can’t code, or can’t make it, there are a number of options for faking it.

• You can fake it with a series of JPEG screens. Use Dreamweaver to create image maps and link them together. You don’t write a single line of code, but you can get feedback on the interaction and flow to see if it makes sense.
• Use Fireworks’ built-in capabilities to link between pages and frames; then generate a clickable HTML prototype.
• Use your favorite PDF creation tool or Adobe Acrobat and link them together for the same result.
• Use PowerPoint to link a series of still screens together.
• Use a series of HTML screens to simulate AJAX and other rich interactions.

At a talk I did for DC Refresh, I discussed a recent prototype we had done for a client. I talked about some of the rich interactions we had incorporated into the prototype with the help of the popular Prototype JavaScript library.

I told the audience I would show them a few basic show/hide interactions we had built into the prototype. I also told them that some of the interactions they would see were real and some were faked. And then I showed them the show/hide functionality for advanced search in Figures 4.3 and 4.4.

Figure 4.3 (Open in Flickr)

Basic search (hide).

Figure 4.4 (Open in Flickr)

Advanced search (show).

I toggled back and forth several times between the two states—showing advanced search and then hiding it. Then I pointed out the two different URLs. This AJAX simulation wasn’t AJAX at all, but rather two different screens linked together. It was faked.

The thing is, it didn’t matter that it was faked. The audience got the concept of show/hide for advanced search.

There are a number of tools out there to fake it, and more than likely you have more than one of them at your disposal. As long as you prime your audience first, set their expectations for what they’re going to see, and then have a simulation that shows what you’ve described, you’re good to go.

Principle 7: Prototype Only What You Need

More often than not, the prototypes you build are going to be pieces of the entire system. You don’t need to build the entire system and get it to work to explore a design or to get feedback on it. In fact, trying to build the entire system loses the inherent benefits of rapid iteration.

If your ultimate goal is to use the prototypes for testing, chances are you’re going to test five to six scenarios. In that case, you only need to build what’s needed for those five to six scenarios.

What happens if a test participant clicks on part of the prototype that hasn’t been built? It’s a prototype. Prototypes are inherently incomplete. If a participant clicks on a feature that isn’t built, you use that as an opportunity to explore how he might expect it to behave.

By prototyping only the pieces you need, your investment is greatly reduced in a number of ways—cost, time, and effort. Additionally, since it takes less time to build only what you need, you’ll get feedback faster and move on. If the small piece you build works, then you can keep going. If not, then there’s no major loss, and you can try something else.

Principle 8: Reduce Risk—Prototype Early and Often

We have these huge firms cranking out wireframes, building things, and discovering problems way too late.

—Anders Ramsay

As we’ve already discussed, prototyping has a number of advantages, one of which is the low investment-to-benefit ratio. Let’s look at two development models—one is the traditional waterfall method and the other utilizes rapid iterative prototyping.

In a traditional waterfall method, all of the system’s features and functions are planned before any development begins. This often leads to a six- to nine-month planning cycle before any actual work on the system begins.

In environments that move slowly or don’t change much, this might not be an issue. In today’s software industry, however, nine months is a lifetime—an entire company can be created bought, sold, and go under in nine months.

But let’s pretend your entire industry moves at the same slow snail’s pace that you do. In that case, you’re so heavily invested at this point that it’s nearly impossible or just not feasible to change direction. The ship has already sailed, and there’s no changing course—there’s no turning back.

This is a very costly model. More often than not, mistakes are made, and the recovery is too costly, as high as 100 percent. As such, these mistakes are left in the system for the end user to try to work around.

The other approach takes a more agile approach. You chip away at bite-sized pieces and use an incremental, iterative, and evolutionary approach. By using this approach with prototyping, you’ve only invested in small amounts. Reducing your investment reduces your risk.

You’re committing a few weeks at a time to a small set of concepts to see if they’re going to work or not. If they don’t work, there’s much less damage that’s done, because you’re only a few weeks away from pulling them and replacing them with something that works better. You’re not stuck for another six, nine, twelve, or eighteen months.

If they do work, you see an immediate benefit. You can make rapid iterative adjustments. You can stay ahead of your market, often leading the space. You can be more proactive and less reactive.

This is an area where prototyping really shines. You make small investments with a significant return. That return can be positive or negative. If it’s positive, then all the better. If it’s negative, then your risk is substantially reduced because you’ll find it early enough in the process and be able to replace it quickly.

The earlier in the development process you catch a mistake, the easier and less costly it is to correct your mistake. And don’t kid yourself—you will make mistakes. By some estimates, changes during design can be as low as 10 percent, and during development or after product launch, your costs skyrocket to 100 percent.

When you start prototyping early and often, you’ll reduce your risk and save yourself a great deal of headache, time, effort, and money.

Summary

Making mistakes in the prototype process is common. Avoiding them is pretty easy when you remember these eight guiding principles:

• Understand your audience and intent.
• Plan a little and prototype the rest.
• Set expectations.
• You can sketch.
• It’s a prototype, not the Mona Lisa.
• If you can’t make, fake it.
• Prototype only what you need.
• Reduce risk. Prototype early and often.

There you have it. Those are the eight guiding principles for effective prototyping. In the next chapter, I’ll discuss the most common prototyping tools being used in the UX community, so you can decide which tool is right for you.