Book Review: Effective Prototyping for Software Makers

Effective Prototyping for Software Makers cover

Review by Leo Frishberg

Published: May 28, 2007

Authors: Jonathan Arnowitz, Michael Arent, and Nevin Berger

Publisher: Morgan Kaufmann, Elsevier, Inc.

Publication date: 2007

Format: Paperback; 9.2 x 7.4 x 1.1 inches; 624 pages

ISBN: 0120885689

List price: $59.95


Last year, I had the pleasure of contributing to Jonathan Arnowitz and Michael Arent’s special issue of Interactions magazine that focused on prototyping. Based on our conversations and the other contributions to that issue, I looked forward to seeing their forthcoming book on the topic.

Organization 3 stars
Content 4 stars
Copyediting 2 stars
Illustrations 3 stars
Book Design 3 stars

I’m a great believer in prototyping as a means of rapid application development and am always looking for ways to improve my craft. Imagine my delight at the prospect of cruising through 600 pages devoted to the subject!

Effective Prototyping is an ambitious undertaking that in some ways redefined the meaning of prototyping for me. No reader is likely to absorb this tome from cover to cover—certainly not in one sitting and maybe never. The authors have tried to include as much information as possible on the topic, resulting in an extensive reference that paradoxically leaves me unsatisfied.

According to the authors, “Effective prototyping uses the right prototyping tool, method, and process given the appropriate need.” Then, the authors suggest that, because there is no other book on the topic, none of us is actually creating “effective” prototypes. This provocative introductory remark is the first of many statements I suspect a good editor would have helped restate. With the gauntlet thrown, my expectations for the book were raised far beyond what the authors could deliver.

I do not fault the sheer volume of information the book provides. For many, especially those new to the notion of prototyping, the breadth and depth of discussion about prototyping would make Effective Prototyping an excellent textbook. Irrespective of your experience with prototyping, the book would be an excellent reference manual—especially in support of your efforts to integrate prototyping into your software development processes.

“For the uninitiated, the first half of the book makes the case for doing appropriately scaled and designed prototypes. For the guru, the latter half of the book brings together, in one easy-to-scan collection, several techniques and how-to’s for creating prototypes.”

For the most part, I do not fault the overall organization of the book. The authors break the topic into four logical chunks that are typical of any development effort.

I do not take issue with the need for this book. I believe it is an important topic, with which every software development team should be familiar, if not facile. I even agree with the authors’ primary thesis that much of the prototyping being done today is ineffective—either underachieving or overachieving.

My primary criticism of the book is that it’s just too much. It covers too much ground in too much detail. Additional editorial cycles would have helped. The prose could be much crisper and make its points much more succinctly.

What frustrates me most about the book is its structure—it practically screams to be a workbook, but the authors have not designed it to work as one.

Lastly, I take issue with that argument the authors posit in the Preface: That, because no book on this topic has existed before, nobody has been building “effective” prototypes. This statement might reveal a too narrowly conceived audience. Perhaps the authors believe their book is best suited for software development teams who are doing prototyping too late, with too much investment, or worse, teams who are not doing it at all. I believe the book is suitable for the uninitiated and the guru alike—each for different reasons.

For the uninitiated, the first half of the book makes the case for doing appropriately scaled and designed prototypes. For the guru, the latter half of the book brings together, in one easy-to-scan collection, several techniques and how-to’s for creating prototypes.


“Each chapter is organized according to need, without following any global template.”

The Preface and first couple of chapters provide historical background, present a bird’s eye overview of the authors’ prototyping process, and most importantly, establish their thesis about “effective prototyping.”

After providing these initial background discussions, the authors cover their remaining material in a logical flow of four phases: planning, specifying, designing, and implementing prototypes. Each phase comprises chapters that cover more specific topics, which are, for the most part, appropriate to the phase.

  • Phase 1: Plan Your Prototype—Covers developing requirements through defining prototype fidelity.
  • Phase 2: Specification of Prototyping—Describes prototype “characteristics, methods, and tools.”
  • Phase 3: Design Your Prototype—Provides a series of design criteria and a heuristic for designing a prototype.
  • Phase 4: Results of Prototyping—Begins with review, validation, and deployment and concludes with several chapters on specific prototyping methods.

It isn’t practical to try to describe all of the chapters in depth in this review. Nor is it possible to simply describe one chapter as an example that is representative of all the others, because each chapter is organized according to need, without following any global template. Again, this approach to the material suggests that at least one additional cycle of editing and graphic design could have improved the readability of the text.

In brief, the book includes the following:

  • Table of Contents

A detailed listing of each chapter’s title and subheadings that helps provide an overview of the entire book.

  • Preface

In their Preface, the authors make a strong argument for “effective prototyping” and describe issues with waterfall software development practices. The preface also presents the structure of the book, introducing its four phases and eleven steps.

  • Chapter 1—Why Prototyping?

In this chapter, the authors offer definitions of prototyping, give some of the history of prototyping, and provide some rationales and justifications for prototyping. This chapter also introduces “ArnoSoft”—the fictional company that is the focus of scenarios at the end of each chapter.

  • Chapter 2—The Effective Prototyping Process

This chapter describes the authors’ eleven-step process in brief.

Phase 1  |  Plan Your Prototype

  • Chapter 3—Verify Prototype Assumptions and Requirements

The authors explain how prototyping transforms assumptions about a product’s design into bona fide product requirements.

  • Chapter 4—Develop Task Flows and Scenarios

This chapter presents several techniques for documenting user tasks and creating scenarios.

  • Chapter 5—Define Prototype Content and Fidelity

In this chapter, the authors describe the relationship between a prototype’s fidelity and its content.

Phase 2  |  Specification of Prototyping

  • Chapter 6—Determine Characteristics

The authors describe eight characteristics of prototypes and why they are important.

  • Chapter 7—Choose a Method

The authors present nine different prototyping methods and give guidance for determining which method to use on a specific project as well as examples of each prototyping method.

  • Chapter 8—Choose a Prototyping Tool

In this chapter, the authors distinguish between methods and tools and describe how to determine which tool to use.

Phase 3  |  Design Your Prototype

  • Chapter 9—Establish the Design Criteria

The authors describe 18 visual and user interface design guidelines and provide a method to assist prototypers in determining which guidelines are most relevant to their prototypes.

  • Chapter 10—Create the Design

In this chapter, the authors provide a method for bringing together guidelines and requirements to “achieve best practice design” for a prototype.

Phase 4  |  Results of Prototyping

“The authors have provided extensive references at the end of each chapter that add value to the subject matter.”

In chapters 11–13, the authors describe the iterative process of refining a prototype.

  • Chapter 14—Card Sorting Prototyping
  • Chapter 15—Wireframe Prototyping
  • Chapter 16—Storyboard Prototyping
  • Chapter 17—Paper Prototyping
  • Chapter 18—Digital Interactive Prototyping
  • Chapter 19—Blank Model Prototyping
  • Chapter 20—Video Prototyping
  • Chapter 21—Wizard-of-Oz Prototyping
  • Chapter 22—Coded Prototyping
  • Chapter 23— Prototyping With Office Suite Applications
  • Chapter 24— Prototyping With Visio
  • Chapter 25— Prototyping With Acrobat

The authors have provided extensive references at the end of each chapter that add value to the subject matter. For individuals wanting to learn more about a chapter’s topic, the authors have done the community a great service in providing these citations.

  • Glossary
  • Subject Index


“One of their primary messages is that the steps are “meant to be scaled” to fit a project’s overall prototyping effort.”

A quick review of the table of contents, which I’ve summarized in the previous section, provides a snapshot of the depth and breadth of the content the authors cover in Effective Prototyping. The heart of the book, Chapters 3 through 13, describes the authors’ eleven-step process for creating prototypes that effectively address the key needs of a software project.

One of their primary messages is that the steps are “meant to be scaled” to fit a project’s overall prototyping effort. In other words, a month-long prototyping effort requires more planning than a half-day prototyping effort, but in neither case should you dismiss any of the steps without due consideration.

In many ways, the process for designing prototypes that the authors describe is not distinguishable from a process for creating software itself: requirements definition and strategy planning, tools and methods of implementation, design, and implementation.

One major omission I noticed in the content was the lack of coverage of Flash as a prototyping tool. Given the target audience for the book, the likelihood their might be a Flash programmer on a team, and the real advantages of that application in creating high-fidelity prototypes, I was surprised to see only one sidebar discussion on Flash. I’m still looking for a definitive book on the topic of creating prototypes using Flash—anyone up to the challenge?

“The content of the book is overwhelming, not only because there is so much to absorb, but because it is organized in a linear fashion.”

As mentioned above, the content of the book is overwhelming, not only because there is so much to absorb, but because it is organized in a linear fashion. The authors discuss topics serially, with all supporting material placed in line. When opening the book to any section, readers will likely need to back up several pages to get oriented to their target subject and, along the way, might encounter several different sidebars, worksheets, or other interruptions to the flow.

The authors could have restructured their content as a workbook, providing worksheets on facing pages, and presenting samples, sidebars, tips, and hints separately from the main discussion.

In this book, the authors have really combined two books into one. Chapters 1–13 are about the theory of creating effective prototypes, and Chapters 14–25 are about building prototypes using various techniques. Perhaps the authors should have separated the latter chapters of the fourth phase into their own complete volume.

A gimmick the authors use to illustrate their points—concluding each chapter with a scenario-like narrative about the struggles of a fictional company to create a new Web site—does not help summarize the chapters’ points. The chapter content should have been sufficient to illustrate the process. Including these narratives either should not have been necessary or they should have illustrated points that were too difficult to communicate in any other way. Instead, these narratives come off as corny and overly simplistic, and in the end, detract from the main message of each chapter.


“The authors would have benefited from a good editor.”

As I’ve already mentioned—and as might be evident from a brief review of the phase and chapter titles—the authors would have benefited from a good editor.

Typos (“acknowlegements”), odd word forms (“inventorize”—okay, a non-standard, possibly British form of inventory, but it certainly doesn’t add any value here), and inconsistent grammar and voice, in both descriptive text (“Similar to paper prototyping, digital prototype (sic) is created from a collection of screen designs.”) and directive text (“If you’re going to collaborate with other members of a team on a prototype, you may want to take stock of their software skills as well and select tools that everyone has common skills and experience with.”) indicate that at least one more round of editing was in order.


“The copy contains numerous illustrations that support the points the authors are making.”

The copy contains numerous illustrations that support the points the authors are making. Illustrations that support the narrative include color photographs, color images of prototypes and Web pages, diagrams, wireframes, and process flows. All figures have appropriately brief captions in the margins—the only use of margins for content throughout the book. The content also includes many diagrams of the various steps of the prototyping process.

The “step-by-step” diagrams—and there are several different types peppered throughout each chapter—communicate clearly the various steps in the process the authors propose. Reducing their prominence in the main text would have made them less distracting and more useful as wayfinding elements.

Book Design

“Perhaps the least successful aspect of the book is its design.”

Perhaps the least successful aspect of the book is its design. As mentioned previously, I think the book wants to be a workbook—or at least would benefit from a companion workbook.

On the positive side, the cover is a creative attempt at communicating the focus of the book—turning rough prototypes into finished products. It also foreshadows many of my concerns about the book in general: a little busy and perhaps trying to do too much.

The paper—a slightly creamy white—has a nice matte finish that provides a clear, bright background for the text, photographs, diagrams, and illustrations.

The tables of contents—there are several, the main one at the beginning of the book and the secondary ones that open some chapters—are detailed, reflecting the density of the subject matter. This level of detail, along with a lack of leaders between the headings and the page numbers, reduces the overall usefulness of the main table of contents.

Some places where a different approach would have made the book more approachable and usable include:

  • clearer separation between body text and sidebar examples
  • heading and subheading typography that clearly distinguishes main points from subtopics
  • reduced emphasis on the process diagrams—either by fading their colors and/or reducing their size
  • placing those process diagrams in the outer margins to reduce interruption of content flow
  • more consistent page layouts to help guide the reader through the topics

For example, Chapter 3, “Verify Prototype Assumptions and Requirements,” begins with a fairly long introduction, then its first section, “Prototyping Requirements Are Not Software Requirements,” ends with a lengthy sidebar discussion about requirements that, because it appears in line with the main text flow, interrupts the authors’ primary narrative.

Similarly, a process diagram showing three steps immediately interrupts the next section, “Transformation of Assumptions to Requirements.” Instead of interrupting the main text, if the authors had placed the diagram in the margin and reduced its emphasis, the diagram could have acted as an orienting landmark for the accompanying subject.

There are more interruptions in the subsections that explain the steps in detail. “Step 1: Gather Requirements” includes a paragraph of text, then a useful worksheet, and in line with the main text, a sidebar presenting an “Informal Process Tip” that if placed alongside the main text would have been less disruptive.The sample worksheet, in progressive stages of completion, breaks up both “Step 2: Inventorize the Requirements” and “Step 3: Prioritize Requirements and Assumptions.” The problem, in each of these cases, is not the content—all of the content is quite useful, dense even. It’s the freeform approach to the content’s presentation that leaves me a bit dazzled.

The interruptions continue throughout Chapter 3. The next section, “Requirements and the Big Picture,” presents an overview of the process of turning assumptions into requirements. Here again, the content is spectacular—the authors are able to condense a wide range of activities into a few pages. However, the manner in which the content is presented—narrative interwoven with process flows intermingled with photographs of examples interrupted periodically by indistinct subheads—fails to do the content justice.


“In spite of the challenges this book presents to the casual reader, I would recommend it to anyone who considers prototyping an integral part of the software development process.”

In spite of the challenges this book presents to the casual reader, I would recommend it to anyone who considers prototyping an integral part of the software development process. If you have never used prototyping to make your products more usable and better targeted—while ultimately reducing your workload and simultaneously improving your code—this book provides a thorough discussion of the topic.

Even if you are a seasoned prototyper, the likelihood is high that you work with others on your team who are not as experienced with prototyping. Effective Prototyping provides a lot of ammunition as you make your case for integrating prototyping into your software development projects—whether your audience is management, development teams, or less experienced designers.

Although you may use just a few of the tools and methods the last half of the book describes, seeing all of the examples of how to render prototypes using off-the-shelf applications could provide inspiration for your own prototyping approaches.

My saying that the book overreaches and was perhaps too ambitious are not completely critical remarks. They suggest that the book contains more than any one individual could use. In addition, I believe the book could have benefited from several more editing cycles to reduce the volume of its content and improve its readability. I also believe it would have been better separated into two or three books—theory, a workbook, and a techniques book.

Don’t let these criticisms dissuade you from picking up Effective Prototyping. If you are looking for complete coverage of the topic, you won’t find any other book like it on the market.

1 Comment

I think prototyping is evolving into the next phase of requirements definition with the addition of annotation tools such as Protonotes.

Written specs have their shortcomings—as do visual prototypes. Putting a written conversation in the context of a prototype can be very powerful.

Join the Discussion

Asterisks (*) indicate required information.