Chapter 1: The Value of Prototyping

Every year, millions of people get a glimpse into the future—the concept car. Manufacturers invest several years and millions of dollars into these one-of-a-kind creations. Most of them never make it to mass production. Those that do are often a fraction of the original vision.

The automotive industry is highly competitive. Innovation is not only a means to stay ahead, but also often one of survival. Each concept is an exercise in design, an exploration into what’s possible, what’s feasible, and what’s marketable—it’s a prototype.

This method of prototyping has been a core part of the auto industry for decades. While these concept cars are expensive, it’s much more expensive to retool all the necessary machines and launch a failure. The risk is too high.

Making the argument that prototyping is a necessary part of the overall design process for something like a car or a missile guidance system is a no-brainer. However, in the world of software development, the argument for gaining buy-in for creating a prototype is a bit more challenging. In fact, it’s typically one of the greatest challenges we have.

In this first chapter, I’m going to highlight some of the challenges faced when trying to incorporate prototyping into an existing design/development process. I’m also going to give you a few pointers to show how valuable prototyping can be to identify problems early on, reduce risk, and ultimately save time, effort, and money.

Clients and management who aren’t familiar with prototyping often see it as a cost with little, if any, benefit. It’s one of the most common questions I’ve received, “How do I get my boss or client to buy into prototyping? They say we don’t have the time or budget for it.”

If your business is involved in building Web sites, software applications, or systems that have both a hardware and software component, you can’t afford not to prototype. As the complexity of the system increases, the cost-to-benefit ratio of prototyping increases dramatically.

Prototyping does have a cost. It isn’t free. But if you haven’t been proto-typing, you’ve been missing opportunities for innovation and significant cost savings. The benefits of prototyping far outweigh the initial cost.

Prototyping Is Generative

One of the fundamental values of prototyping is that it’s generative, which means as you work through the prototyping process, you’re going to generate hundreds, if not thousands, of ideas. Some of them are brilliant and some are less brilliant. I’ve found that even those less brilliant ideas can be a catalyst for brilliant solutions.

As a generative process, prototyping often leads to innovation and a significant savings in time, effort, and cost. Prototyping helps you get ideas out of your head and into something more tangible—something you can feel, experience, work through, play with, and test.

Prototyping—The Power of Show, Tell, and Experience

If a picture is worth a thousand words, then a prototype is worth 10,000. Prototypes go beyond the power of show and tell—they let you experience the design.

“It’s one thing to talk about them and have storyboards and another thing to see them for real.”

—Robert Hoekman, Jr.

There are a number of ways to communicate or document a design, including requirements documents, wireframes, visual comps, and prototypes.

Common Design Documentation Models

Requirements documents. These are typically a written document describing the technical or functional requirements of a system. Requirements documents tend to be more focused on written description and less on visual illustration—they are more tell and less show. The lack of visual simulation often leads to misinterpretation of a requirement. Screen shots can be included to help reduce this misinterpretation, but static screens only go so far.

Wireframes. Ever seen architectural blueprints for a house? Well, that’s kind of what a wireframe is for software. Wireframes are a visual representation of the functional page structure. They visually communicate what functional pieces are present on a page and their relationship to each other. Wireframes are typically in black and white or shades of gray.

Combined with detailed behavior notes, wireframes do a better job at show and tell than requirements. However, wireframes often leave gaps in the design. These gaps result in missing details or misinterpretation, which is bad.

Prototypes. A prototype is a representative model or simulation of the final system. Unlike requirements documents and wireframes, prototypes go further than show and tell and actually let you experience the design.

Some technical requirements, like a 100KB page limit, might not be obvious in a prototype. These can easily be captured with a supplemental document much smaller than 60–200 pages.

On its own, a requirements document or wireframe is insufficient for show and tell of complex systems. You might be able to get by using one of these for simple systems, but for complex systems, you’ll ultimately run into trouble. Oftentimes, they are used together in the attempt to create a “full picture.” However, they still fall short when it comes to actually experiencing the design.

Combining annotated wireframes with a requirements document can get you to a 70–80 percent accuracy of the original vision. That’s still too much room for error in my book.

The AJAX and RIA Monkey Wrench

Now, what happens if you throw AJAX or other Rich Internet Applications (RIAs) into the mix? Things start to fall apart—rapidly. Neither a requirements document nor annotated wireframes do a good job at telling the story of rich interactions and transitions.

Unlike traditional page-based interactions, AJAX and RIAs often leverage state-based interactions. A page or screen can have several tiles or widgets that operate independently and interdependently of each other. Updating an RSS feed on a page doesn’t require refreshing the entire page anymore. Instead, only the RSS feed widget updates, leaving the rest of the page alone.

This has prompted many in the design community to claim that the page paradigm is dead—the new paradigm is the screen or state.

Transitions and animations are another challenge. Have you ever tried to describe a self-healing AJAX transition? My best description, coupled with some strategic hand waving and magic wand simulations, still results in raised eyebrows and questionable looks.

As the presence of AJAX and other RIA technologies continue to grow, the need for and value of prototypes as a design communication tool dramatically increases. In fact, I would argue it becomes critical for success.

Prototyping Reduces Misinterpretation

Take a 60-page requirements document. Bring 15 people into a room. Hand it out. Let them all read it. Now ask them what you’re building. You’re going to get 15 different answers. Imagine trying the same thing with a 200-page requirements document—it gets even worse.

Prototypes are a more concrete and tactile representation of the system you’re building. They provide tangible experiences.

Once my company made a shift away from a requirements-dependent process to a prototype-dependent process, we saw an immediate reduction in the need for clarification and rework. We’ve gone from a 60–80 percent consensus on interpretation to 90 percent or better.

We’ve also found that the total amount of time and effort required to produce the prototype is less than that required to create a detailed specification document and annotated wireframes.

I’ve found a number of reasons that written documentation leaves more room for misinterpretation:

• Nobody wants to read a 60–200-page written specification. There’s really no joy in it.
• If you can’t get them to read it, you won’t get them to fully understand it.
• Written documentation doesn’t allow you to see the “big picture.” Instead, you’re forced to see one line at a time.
• Words leave too much room for interpretation.

Prototypes, on the other hand, have a number of advantages that help reduce misinterpretation:

• You experience how the system would work, rather than just read about it.
• Prototypes encourage play. When you get someone to play with your prototype, you increase the likelihood that they’ll understand it.

Prototyping Saves Time, Effort, and Money

How many times have you heard one of the following from a client, one of your bosses, or even a fellow designer or developer?

“We don’t have time to prototype.”

“We can’t afford to prototype. We don’t have the budget for it.”

I’ve heard each of these arguments dozens of times. Frankly, they’re not without some merit. As I said earlier, prototyping isn’t free, but the benefits of prototyping far outweigh the cost of prototyping, or most importantly, not prototyping.

Talk to anyone who has made the transition from a design and development process that didn’t include prototyping to one that does, and they’ll tell you it has saved them a ton of time and headaches. Not only does prototyping let you realize and experience the design faster, but ultimately it also reduces the amount of waste created by other design and development processes.

Prototyping Reduces Waste

In a typical design and development process, requirements are written and handed off to a designer or developer. The designer or developer then interprets these requirements and builds something based on his/her interpretation.

Theoretically, a requirements-driven design process should reduce waste. The overall goal is to get everyone on the same page. If we’re all on the same page, ultimately, we’ll have less waste. Sounds fantastic.

Theoretically, it’s a very sound idea. As experience will show, however, theory and reality are often very different. There are a number of shortcomings in a traditional requirements-driven design and development process that create waste, and they include the following:

1. Written by the wrong person. Designers and developers are rarely included in the requirements writing process. Instead, the requirements are often written by a business analyst or his equivalent. This person lacks the technical and design knowledge of their counterparts, which often results in any number of requirements being rewritten several times.
2. Significant time and effort. The amount of time invested in writing, reviewing, and revising these detailed requirements is significant. For complex systems, I’ve seen it take 3–9 months to finish something—sometimes more. During that time, things change.
3. Non-final final. Theoretically, the requirements are the final documentation. In reality, requirements are constantly changing, even after they’re “complete.”
4. Misinterpretation. The amount of misinterpretation of the 60–200-page requirements is often significant. Misinterpretation leads to weeks or months of rework and a delayed product launch.
5. Nonessential features. Requirements are often filled with features that provide little, if any, value. Those features take time and effort to build and test. This results in wasted time in writing requirements, building, and testing features that provide little, if any, value and often go unused.
6. Catching mistakes too late. Requirements-driven processes typically won’t catch a mistake until it’s in production. The later you catch a mistake in the development process, the more costly it is to fix.

Any one of these items alone creates wasted time and effort. Typically, a requirements-driven process is plagued with several of these issues, creating a great deal of inefficiency and waste. On the other hand, including prototyping in the process can help reduce the amount of waste and result in these benefits:

1. Decisions by the right people. Designers and developers can flex their experience and knowledge, contribute to the process, and ultimately ensure that the right people make the design decisions.
2. Survival of the fittest. Multiple ideas are created and tested to ensure that the strongest solutions survive.
3. Adaptive. Prototypes can be quickly updated, compensating for the ever-changing nature of software development.
4. Reduced misinterpretation. The prototype is a visual, or sometimes physical, representation of the system. Visual and physical representations leave less room for misinterpretation than a 60–200-page written document. By reducing misinterpretation, you reduce the amount of rework. Less rework means lower costs and faster time to market.
5. Focus. Prototyping produces more focused products. More focused products produce less waste in design, development, and rework.
6. Catch mistakes early. Prototyping helps you catch mistakes early in the design and development process. The earlier you catch a mistake, the lower the cost to fix it will be.
7. Reduce risk. Prototyping reduces risk, by reducing misinterpretation and catching problems earlier in the design and development cycle.

While prototyping can’t solve all the problems that plague requirements-driven processes, it can definitely help reduce many of the more common inefficiencies and waste.

Prototyping Provides Real-World Value

Jonathan Baker-Bates is someone who has seen a measurable benefit from prototyping firsthand. Jonathan works for a consulting company in the UK with a very typical design and development story. His team of developers regularly receives a 200-page specification document to quote against and build to. Well, that was what they used to do.

Jonathan’s company recently made a shift toward a prototyping-oriented process. Instead of giving developers a 200-page document, they now receive a high-fidelity prototype with a 16-page supporting document.

Since the change, his company has noticed a number of significant improvements:

• Time and effort required to produce the prototype and 16-page supplemental document is less than half required for the 200-page specification document.
• Estimates for build time and cost have become 50 percent more accurate.
• Request for clarification by the development team has been reduced by 80 percent.
• The amount of rework and bug fixes post-launch has been reduced to 25 percent of similar previous projects.
• All team members agree that executing the design with the prototyping process is easier than the old process.

Case Study: Prototyping with Tight Budgets and Deadlines

by Jonathan Baker-Bates

With less than four months to design and build a “social” Web site for a major computer games developer, we had a strong visual design concept, a number of broad content and functionality requirements, and a team of in-house developers ready to go with a CMS. But budgets were tight, and there were plenty of uncertainties about the scope of the project. This was also the first time we had worked with this particular client, and they were not the sort who were given to studying large documents (which could often top 200 pages on similar projects). We needed to keep everyone engaged and clear about what we intended to do from the earliest stages.

We decided that from day one of the design phase, all eyes were to be on a functional HTML prototype, which demonstrated the entire site, built and maintained using Axure. With that in mind, we hoped to show almost all the necessary requirements to a level of detail for anyone and everyone to grasp—whether they were a CEO or a CMS integrator.

Of course, the prototype could not show everything. Nonfunctional elements, some conditional screens, and exceptional flows needed to be recorded separately, as well as miscellaneous notes about the implementation. These were captured in a short supporting document of around 20 pages. The one rule that applied to this document was that it would contain only those things that could not reasonably be understood from the prototype.

This was important to minimize our overhead and prevent the document from running out of control.

The first thing we noticed was that the prototype removed the need for lengthy “introductory” communication and discussion. People who viewed the prototype became immediately familiar with what we were trying to do in minutes rather than hours or days. That meant that we could turn the discussion back to the details. This rewarded us in a number of ways. First, the accuracy of the build estimates proved to be very high. Second, we also encountered a far lower amount of communication (and problems) about the design overall—perhaps as much as 80 percent less than normal. Finally, when the design later went to integration and testing, it had a relatively smooth passage with about 25 percent fewer bugs being reported against the specification. Budgetary and scope constraints still meant that things were often difficult, but having a prototype meant that we could quickly show how we intended to scale back some requirements to get the client’s sign-off.

For us, this approach proved successful. However, I’d caution readers to remember that all projects are different, and this technique might not have been best in other circumstances. It is also worth noting that we later returned to a more traditional document-based process for incremental changes once the main site had gone live. But without the prototype on hand, we would probably not have been able to deliver when we did.

Jonathan’s story isn’t anything unique. It’s the same story told by people I interviewed for this book. I’ve heard similar stories from dozens of people who have attended one of my prototyping workshops or talks. And it’s been reiterated again by hundreds of respondents to surveys I conducted while writing this book.

Summary

Prototyping can literally shave months to years off your development time. What are you waiting for?

Now that you know the value of prototyping, you should be able to get buy-in from clients or management. Just remember the following key points:

• Prototyping is generative.
• Prototypes communicate through show and tell.
• Prototyping reduces misinterpretation.
• Prototyping saves time, effort, and money.
• Prototyping creates a rapid feedback loop, which ultimately reduces risk.

In the next chapter, we’re going to look at the rapid, iterative prototyping process I use.