Book Review: Effective Prototyping for Software Makers

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

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

Content

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?

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.

Copyediting

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.

Illustrations

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. 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.

Conclusion

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.