Chapter 2: The Prototyping Process

In architecture and product design, prototyping is a given. But that’s not necessarily the case with software development.

—Anders Ramsay

Prototyping is commonplace in other design fields like architecture and industrial design. In fact, it’s not just accepted, but expected.

Why isn’t it as expected in software development? After all, software development, architecture, and industrial design have so much in common, including the following characteristics:

• They are all design processes.
• Artifacts are produced to communicate the design.
• The end result is a tangible product that people can experience and use.

I think the first reason is that in software development, the emphasis is often placed on the development process and not the design process. The industry doesn’t call it “software design”; they call it “software development.”

In software development, design is often an afterthought. The emphasis is on the technology or features—not the design. In architecture and industrial design, however, the emphasis is on design. Form follows function.

Another reason is that software development is seen as a manufacturing process, but architecture and industrial design are seen as a craft.

Perhaps these shortcomings are the result of how each field is taught. Computer science classes focus on teaching students technologies. Architecture and industrial design, on the other hand, focus on teaching students design principles and include something called design studio.

The Absence of Design Studio

In the world of architecture and industrial design, a design studio is a process, not just a physical place. This process is taught in every respectable architecture and industrial design program. You’ll be hard pressed to find a design studio class in computer science.

In studio classes, you design or prototype and present to your peers. Your peers critique your work, highlighting the strengths and areas that still need some work.

When you design, present, and critique, think of it as a collaborative, rapid, iterative design process. During this process, you get to share in the ideas, successes, and failures of your peers.

Design studio is a core part of architecture and industrial design. Prototyping is a core part of that studio process. So students learn this skill early on, and they use it regularly. Prototyping becomes a regular tool in their design process.

What Does the Prototyping Process Look Like?

First, let’s be clear about something—there is no uber-prototyping process, a single formula like there is for Coca-Cola. However, there are a number of tried-and-true guiding principles you can follow, no matter what you’re prototyping.

Second, no matter what prototyping process you decide to use, keep in mind that a process is merely a means to an end. One of the most common pitfalls of following a process is being tied too tightly to it. If you’re more focused on the process than the end goal, you won’t be successful.

Third, a good process balances structure with flexibility. It provides a solid foundation, while giving you the flexibility to change and adapt that process as needed, due to changes in time or circumstance.

Finally, a good process breeds success. When your process starts to limit success, then you need to revisit it.

Mark Sanders, the inventor of the Strida folding bicycles, describes the process he used to create the bikes on YouTube[1]. As I watched Mark describe his process, a few things stood out:

• He didn’t worry about which ideas were good and which were bad. Instead, he used sketching to explore every possible idea.
• Once he had plenty of sketches, he evaluated them based on the original goals of the product. This left him with the best ideas.
• Sketches only go so far. In order to see which of his best ideas would really work, he had to build models or prototypes.
• Sketching also played a critical part in updating the design to create the Strida2.

The process Mark describes in the video is a pretty typical prototyping process, which includes the following elements:

• Sketching
• Evaluation
• Modeling
• Testing

At my company, Messagefirst, we use a similar approach to the one Mark describes, but with a small twist. Our prototyping process takes a page from the design studio book and uses the presentation and critique model for evaluation. So our modified approach looks like this:

• Sketching (e.g., whiteboards, paper, code)
• Presentation and critique
• Modeling (prototyping)
• Testing

Since one of the goals of our process is rapid iteration and evolution, we stress some pretty short timeframes on the first two stages—sketching and presentation and critique. This emphasis on short cycles keeps the process moving and makes us more productive. It also enhances the generative nature of prototyping.

Our prototyping process is also iterative and evolutionary. We sketch, present and critique, prototype, present and critique, sketch, present and critique, prototype, present and critique, prototype, and test (see Figure 2.1). Then we do it all again.

Figure 2.1 (Open in Flickr)

Diagram of the iterative design and critique process.

One thing you might have noticed is the cyclical nature and multiple instances of the first two steps: sketching and presentation and critique. Sketching is woven throughout our prototyping process. Anytime we sketch, we present and critique. In fact, when we’re presenting and critiquing our prototypes, either internally or externally with a client, we sketch our revisions.

Now, let’s taking a detailed look at the prototyping process I use, starting with sketching.

Part 1: Sketching

Sketching is the generative part of prototyping. As part of the generative nature of prototyping, your goal is to get the ideas out of your head and into a more tangible format.

I prefer putting a time limit on “sketching time.” This forces the sketchers to work quickly without getting caught up in the details.

The goal of sketching isn’t to flesh out your ideas fully—you’ll do that during the prototyping stage of the process. The goal is to generate a number of concepts, get them out of your head as quickly as possible, and move on.

Tip Quantity Over Quality

When you’re sketching, don’t worry about good ideas versus bad ideas. The purpose of sketching is to explore ideas. Sketching is where quantity is more important that quality. Quality will come later.

Sketches are typically rough, somewhat incomplete, and frankly, sketchy, like Figure 2.2. Don’t be concerned about making them perfect. Just get the ideas out of your head and make them tangible.

Figure 2.2 (Open in Flickr)

Sketch of Vimeo video browser module showing line weight and labels.[2]

Tip Fast and Furious

Put a time limit on your sketching. I like to do limits of 10–30 minutes and then move on to the presentation and critique stage. These short time limits force you to focus more on producing ideas than getting caught up in the details.

Most of our sketching is done on paper using sketchboards. Sketchboards are just a piece of paper with a bunch of miniature windows for sketching. Sketchboards look like storyboards.

Here’s an example of what one of our sketchboards looks like (see in Figure 2.3).

Figure 2.3 (Open in Flickr)

Sketchboard example showing multiple sketches.

The biggest difference between a storyboard and a sketchboard is that storyboards are used to tell a linear story. Sketchboards, on the other hand, are just intended to capture a bunch of ideas—linear, nonlinear, it really doesn’t matter.

Tip Good Things Come in Small Packages

Using sketchboards is a great way to generate several ideas. The small space encourages you to think about specific parts of the interface. Sketchboards are also flexible enough to be used for a little storyboarding if you need to describe AJAX or RIA designs.

While most of our sketching is done on paper, we will occasionally sketch on whiteboards or in code. Sketch in whatever medium you’re comfortable in as long as it produces results.

Let’s have a quick look at some of the advantages and disadvantages of sketching in code, on a whiteboard, or on paper.

Sketching in Code

Sketching is limited to paper or a whiteboard. Developers often sketch in their medium, which is source code. Just like sketching with paper or a whiteboard, you sketch out your ideas by constructing them with bits of source code.

One of the benefits of sketching with code is the inherent ease of turning your sketches into a prototype. With the increasing number of JavaScript libraries, CSS frameworks, and application frameworks like Ruby on Rails, sketching in code is easier than ever.

Advantages

• It makes sketching in code easier with an increasing number of available tools.
• It brings your sketches to life—you can actually play with your sketches.
• It leverages existing code, when possible.

Disadvantages

• Not everyone can code.
• It requires a computer.
• It’s less collaborative than paper or a whiteboard.
• It takes more time than paper or a whiteboard.

Sketching on Whiteboards

One of the biggest benefits of sketching on whiteboards is its inherent collaborative nature. It’s very easy for anyone to participate in the discussion and sketch on the whiteboard.

Advantages

• It’s collaborative.
• Anyone can draw on a whiteboard.
• More than one person can participate at a time.
• No computer is necessary.
• Revisions are easy—just erase and draw again.

Disadvantages

• It’s less portable than code or paper.
• Sketches are still static.
• Capturing sketches from a whiteboard can be difficult.[3]

Sketching on Paper

Sketching on paper is still my favorite. Similar to the collaborative nature of sketching on whiteboards, paper is ultra portable and can be done anywhere.

Advantages

• It’s collaborative.
• Anyone can draw on paper.
• More than one person can participate at a time.
• No computer is necessary.
• Revisions are easy—just draw over your current sketch or grab another piece of paper.
• It can happen anytime, anywhere.
• It’s definitely portable.

Disadvantages

• Sketches are still static.

Part 2: Presentation and Critique

Presentation and critique is arguably the most important part of our prototyping process. This is where we focus on quality.

Presentation and critique is a technique I learned from studio class during my undergraduate days while studying graphic design. And even though I later changed my degree to English and Cognitive Psychology, I’ll never forget the very valuable lessons learned from presentation and critique.

The goal of the presentation and critique stage is to find the best ideas. You present the strengths of your concept, and your peers highlight areas that need work or further clarification. That’s it—discuss, evaluate, and move on.

When presenting our sketches for critique, we often taped them up on a wall, as shown in Figure 2.4.

Figure 2.4 (Open in Flickr)

Presentation of sketches during a design studio critique session.

Presentation and Critique Guidelines

Keep it short. As I mentioned earlier, presentation and critique is the second stage where we emphasize tight timelines. In fact, presentation and critique time is shorter than sketching time. I like to limit presentation time to two minutes and critique to three minutes.

It’s important not to spend too much time during the presentation and critique step. I know, it sounds a bit counterintuitive. But just like when you’re sketching, the purpose is to get something out quickly and move on. You’re going to refine your ideas later.

Three-minute presentation per concept. A time limit of three minutes per presentation per concept means that you’ll have to focus on the strongest parts. And if you can’t explain your concept in less than two minutes, then something is probably wrong with it.

Two-minute critique. Your peers get two minutes to critique your concept. During the critique, they have to provide two to three things they think are strong about it and one to two areas that need improvement or need to be worked out a bit more.

Take notes. Write directly on your prototype sketches. It’s okay. It’s just paper. Use the critique of your peers to refine and strengthen your design concept.

Part 3: Prototype

At this point in the process, you’ve sketched out your ideas, presented and had them critiqued, and are now left with the strongest concepts. These are the ones you’re going to prototype.

Prototyping is where you start to work out the details of your design and figure out which ones will actually work.

When I prototype, I consider the following details:

• Am I using a tool or medium I’m comfortable in?
• Do I have the ability to communicate effectively what I need to the audience or consumer?
• How much time do I have?
• What level of fidelity do I need?

It really doesn’t matter what you build your prototype in at this stage. Most of my prototypes are HTML/AJAX prototypes, but that’s due to the nature of my work and clients. I’ve also created Flash, Keynote, and paper prototypes.

Once I have a prototype, I repeat the presentation and critique stage. I use the same basic model, presenting a piece of the prototype at a time and offering it up for critique from the client or customer. The biggest difference is when I present a prototype, I increase the time limits on presentation and critique. Other than that, the process follows the same guidelines.

Tip PROJECT AND SKETCH

Project your prototype on a whiteboard during the presentation and critique process. This allows you to sketch on top of your prototype during the process.

Part 4: Test

I divide testing into one of two categories: testing with the client or testing with the end consumer.

Testing with Clients

Testing with the client is a hybrid model of presentation and critique with sketching. These sessions typically last 1.5–3 hours, depending on the complexity of the prototype.

During these sessions, I follow the basic presentation and critique model, presenting one piece at a time and opening it up for discussion. Rather than writing up a list of revisions, I use a sketchboard to create sketch notes. These sketch notes are mostly sketches with a few labels or handwritten notes added.

I’ve found that sketching out the revisions ensures that we all walk away from the table on the same page. Written notes leave too much room for misinterpretation. By sketching the revisions, the risk of misinterpretation is reduced. And since sketching is collaborative, the client can contribute easily to the solution.

Basically, I follow the prototyping process for defining revisions during the prototype process—more sketching, less writing.

Once the design review session is finished, the client gets access to a copy of the prototype, and I ask him to play with it for the next two to three days.

Since one of the goals of a prototype is to get it into the audience’s hands, I want the client to experience it, play with it, and use it. After he does, he’ll either find additional issues, or realize that something he thought was an issue really isn’t.

Testing with End Customers

Testing with the end customer is a standard usability test—8–12 participants, 5–6 scenarios, audio-video capture, analysis, and reporting of results afterward. Check out Chapter 12, “Testing Your Prototype,” for more detailed information on testing your prototype.

In either case, client or customer testing, I incorporate the feedback into the next iteration of the prototype.

Summary

So that’s an overview of the prototyping process I use at Messagefirst. Hopefully, this has helped newbies see how prototyping can improve their design process. And for those seasoned pros, I hope you found a few tips to improve your current prototyping process.

Prototyping is a process, not a product—like any other process, it’s only a means to an end. A few important points to remember when you’re prototyping:

• Sketching is a key part of the prototyping process.
• Use the design studio method of sketching, presenting, and critiquing as a way to iterate rapidly.
• Start with quantity, exploring lots of ideas. Quality will come later.

In the next two chapters, we’ll look at the five different types of prototypes and the eight guiding principles for better prototyping.