Books & People

back Books & People Overview

Books, People

Archives

Book Reviews

 

Book Review: Effective Prototyping for Software Makers

Book | Authors | Review

By Gerd Waloszek, SAP User Experience, SAP AG – Updated: January 12, 2009

This review takes a combined personal look at the book Effective Prototyping for Software Makers by Jonathan Arnowitz, Michael Arent, and Nevin Berger.

 

Book

Cover of Effective Prototyping     

Jonathan Arnowitz, Michael Arent, and Nevin Berger
Effective Prototyping for Software Makers
Morgan Kaufmann, 2007
ISBN: 9780120885688

Design: Prototyping

 

Authors

Photo of Jonathan Arnowitz

Jonathan Arnowitz is a User Experience Architect at Google Inc. Most recently, Jonathan was at SAP Labs and the former co-editors-in-chief of Interactions Magazine. Jonathan was a senior user experience designer at PeopleSoft and a leading HCI consultant in the Netherlands. He is a member of the SIGCHI extended executive committee, and was a founder of DUX, the first ever joint conference of ACM SIGCHI, ACM SIGGRAPH, AIGA Experience Design Group, and STC.
(From Website www.effectiveprototyping.com/about_authors.shtml, adapted and updated)


Photo of Michael Arent

Michael Arent is the Vice President of SAP Business Objects User Experience at SAP Labs, and has previously held positions at PeopleSoft, Inc., Adobe Systems, Inc., MetaDesign, Sun Microsystems, and Apple Computer, Inc. He holds a number of U.S. and international patents.
(From Website www.effectiveprototyping.com/about_authors.shtml, adapted and updated)


Photo of Nevin BergerNevin Berger is design director at Ziff Davis Media. He was Previously a senior interaction designer at Oracle Corporation and PeopleSoft, Inc., and has held creative director positions at World Savings and OFOTO, Inc.
(From Website www.effectiveprototyping.com/about_authors.shtml, adapted)

 

Review

SAP User Experience colleagues Jonathan Arnowitz (now at Google Inc.) and Michael Arent, together with Nevin Berger from Ziff Davis Media, have invested a great deal of time and effort to put together Effective Prototyping for Software Makers, which is probably the most comprehensive book about prototyping for software applications to date – or , as Don Norman puts it in his endorsement: "Everything you ever wanted to know [about prototyping], but had no idea who to ask." Indeed, considering its more than 550 content pages, the book should hardly leave a question about prototyping unanswered. The authors themselves characterize their book and its purpose as follows: "This book is an attempt to make the prototyping process not just understandable and manageable but also doable – by anyone with the desire to improve a product's design and learn more about the users' needs." However, before readers will be ready to manage prototyping, they will have to manage to get through this lengthy book. I therefore propose some shortcuts for readers in a hurry further down in this review.

The authors describe a second goal of the book as follows: "With this book explaining the characteristics, methods, and tools of prototyping, in addition to where and how prototypes fit in the software creation process, we hope to shift the priorities of software making towards software conception, design, and usability." So they not only want to improve the skills of individuals, their target is also to improve the software creation process as a whole, and to shift its focus from technological requirements to human needs.

Let me start by discussing a few terms from the book's title – one has already been mentioned in the previous quote:

  • Software Makers: The authors introduce the term "software making," because they regard "software development" as misleading and too close to engineering. Bill Buxton's filmmaking analogy for the production of software applications inspired them. For Bill Buxton, creating software is more like making a film: Writing the script and casting the characters in advance and then iterating on them. This approach is in stark contrast to the classical waterfall model of software design, where one stage leads to the next in an orderly fashion. The authors also consider a wider range of people who are involved in the software making process: For them, a software maker is more or less everybody who participates in the multi-disciplinary process of creating a software product, not just the people who produce the code (and who are called software developers...). Certainly, this point of view has consequences: You need prototyping tools that can be used by everyone and require a minimum of coding – if any at all. You will find out that the authors take this issue seriously, particularly in the last part of the book (chapters 23-25).
  • Underachieving and Overachieving Prototypes, Effective Prototyping: The authors' goal is to make everyone an "effective prototyper." To clarify what this means, they contrast the term "effective prototyping" with two others, namely "underachieving" and "overachieving" prototypes. According to the authors, a typical overachieving prototype shows inappropriate high fidelity too early in the software creation process. A prototype is referred to as underachieving if it is too vague or ambiguous, leaving too much room for interpretation. In the first case, design discussions may be closed too early, often resulting in costly design revisions at a later stage. In the second case, the implementation may go astray or flounder. Effective prototyping tries to avoid these pitfalls by defining "a learnable and repeatable process" that is based on the current requirements and needs of the organization that is building the software. It is meant to ensure that the right tools, methods, and overall process are used, thus making the process effective.

Readers will also find that the authors regard the classical distinction between low- and high-fidelity prototypes as falling too short. Instead, they propose to identify the prototyping content first and then adjust the fidelity level for each of the following content types separately: information design, interaction design and navigation model, visual design, editorial content, branding, and system performance/behavior. In addition, they complement fidelity with seven primary characteristics that help to select the appropriate prototype: audience, stage, speed, longevity, expression, style, and medium.

Short Overview of the Book

Effective Prototyping for Software Makers consists of four main parts (please note that these parts are not reflected in the book's table of contents: I introduce them here to provide readers with a better overview of the book's content).

  1. In the introduction, comprising the first two chapters, the authors provide a rationale for prototyping and outline what they consider to be an "effective" prototyping process. Thus, chapter two can be regarded as an advance organizer for the subsequent and largest part of the book, which covers the prototyping process at length.
  2. The recommended process consists of four phases – plan, specification, design, and results – comprising, all in all, eleven steps, which are covered in the following eleven chapters, 3 to 13.
  3. Part three, consisting of chapters 14-22, describes selected prototyping methods without resorting to specific tools. In short, methods are "what can be used to create a prototype; for example, storyboards, wireframes, paper, etc."
  4. The fourth and last part is a hands-on section presenting three software tools – some of which may seem surprising choices in the prototyping context – which can be used even by non-programmers: Microsoft Office applications (Word, PowerPoint and Excel), Microsoft Visio, and Adobe Acrobat.

The book is accompanied by a useful glossary explaining terms that are often encountered in the context of prototyping. Readers who would like to dig deeper into a specific topic will find a collection of references at the end of most chapters.

For more details about the content of the book, see my extended summary.

Into the main thread of the book, another thread is woven: the Arnosoft story. It illustrates and extends certain topics with "real-world examples" from a fictitious software company. In addition, the authors present examples from their own experiences as prototypers where appropriate. Last but not least, they provide worksheets and checklists, which may help readers in making their decisions transparent throughout the prototyping process. The authors promise to make these resources available on the book companion Website.

Reading Shortcuts

Here, I would like to offer a few hints for managing this voluminous book and provide a few reading shortcuts:

  • If you need a concise overview of the prototyping process, as the authors propose it, read chapter 2, The Effective Prototyping Process.
  • If you are already familiar with the overall prototyping process and want to jump right into prototyping, go to chapter 7, Choose a Method, for an overview of the prototyping methods presented in the book and for guidance in selecting the right method. Chapter 8, Choose a Prototyping Tool, then provides you with criteria for selecting the appropriate prototyping tool for the method of choice. Afterwards, you may want to enlarge upon the method that you took into closer consideration and consult the respective chapter in part III, Selected Prototyping Methods (see extended summary). If you are unsure about the prototype characteristics used to describe the method, consult chapter 6, Determine Characteristics.
  • To learn more about prototyping tools for everyone, you can jump right into the respective chapters at the end of the book – they are largely independent from the remainder of the book.

Nearly every introductory and process-related chapter contains a summary at the end. For readers in a hurry, I would suggest starting with chapter 2, The Effective Prototyping Process, and then scanning the summaries to get a quick overview of the content of the first half of the book.

Comment

The book provides a wealth of information on software prototyping and has rightfully received much praise for this. So I do not want to reiterate this aspect here. Perhaps I may make just two remarks: Prototyping can take many, many forms. As the authors strive for completeness, the book sometimes appears a bit wordy and undecided with respect to the many options within a process or methods. For beginners, this may be confusing at times, and some additional guidance would probably be preferable. Also, compared to the process aspect, the hands-on aspect of prototyping has been somewhat neglected in the book. That is not so much a problem for beginners to the UI field, but more so for experienced practitioners. The authors have promised me that they will add more hands-on examples to the book companion Website – and hopefully to future editions of the book, too.

In the following, I would like to add some general comments. The authors set off to establish prototyping as an integral element of the software creation process. Therefore, a large part of the book deals with the prototyping process to ensure that prototyping is fully integrated into the software making process and thus effective. Based on my own experience, I feel confident that the authors would appreciate it if designers read the process part first, instead of proceeding straight to the hands-on part of the book. Nevertheless, I suggested some shortcuts for readers who are pressed for time.

The authors also rightfully caution readers that prototyping might fail if market- and company-specific constraints are not considered. And in order to help avoid failure and to promote effective prototyping, the book presents the "ideal" prototyping process, as the authors understand it. This approach makes sense in environments where a user-centric design process has been successfully established or where there is no established process and designers need orientation. There are, however, environments where it is impossible to implement the ideal process. One reason is that large companies, and SAP is no exception in this respect, have already established software creation processes, which may differ from the described process in various ways. At what stage in the software creation process prototyping is used, what purposes it serves, and which methods and tools are used – all these aspect may already be "givens." The designers no longer have the freedom to choose. In cases like these, the book may provide designers with a broader view and may encourage them to help improve the current process in their company.

Comparing my own prototyping practice with the book, it looks as if it were "outside of the scope of this book," firstly because of the practice itself, and secondly with respect to the tools that I use. Let me begin with the "practice" aspect. In theory, a company may or may not have an established process that prescribes where prototyping fits in and which methods and tools are to be used. In practice, there may be a lot of "quick-and-dirty" activities going on in parallel to the official process – provided there is one at all–, and we may find many deviations from the "ideal" process. But let me ask: Isn't prototyping somehow a synonym for "quick-and-dirty?" Shouldn't we expect deviations from the ideal prototyping process? I have created lots of prototypes over the years, and only a few followed a "principled" approach, such as the one described in this book. Does this mean that my prototyping was inherently ineffective? The authors would probably reply with a firm "yes." Their effective prototyping process is an attempt to prevent failures and ensure effectiveness. In a way, it is like providing prototyping activities with a safety net. For me, however, a safety net and prototyping as a quick-and-dirty activity do not fit together. Therefore, I, and probably many readers, too, would have welcomed a few words in the book on the "darker" or "quick-and-dirty" sides of prototyping. But I firmly believe that the authors purposely did not mention these aspects, because that would have undermined their mission.

I also found that the prototyping tools I primarily use only play a minor role in the book – for a good reason: They are specialists' tools. I created most of my early prototypes with Adobe Photoshop for demonstrating screen redesigns. Later, I mostly created HTML prototypes at different degrees of fidelity, particularly for Web applications and Websites. It is also worth mentioning that many of my prototypes were only needed once. Therefore, my primary design criteria were – apart from promoting an improved design – speed and efficiency. I put into the prototype only what was needed for the respective purpose. In conclusion, I would like to modify a famous quote from Albert Einstein (who is listed in the book as a source of inspiration by Nevin Berger): Every prototype should be made as simple as possible but not simpler. With respect to prototyping tools, I agree with the authors: Use the ones that fulfill the purpose fastest for you and your "customers."

Suggestions for Future Editions

I would like to make a few suggestions to the authors for inclusion in future editions of the book. First, practitioners would probably welcome a list of the worksheets and checklists offered throughout the book as a useful addition.

Not all readers will read the book from from start to finish. While thorough reading may be advisable for the introductory and process chapters, it is, in my opinion, not required for the remainder of the book. Therefore, I would like to make a second suggestion, which was inspired by a flower guide that I own. This guide classifies flowers primarily by the colors of their blossoms. The page edges are colored to match the color classifications of the flower. This means that I can easily turn to the right section of the book. Color-coded page edges would probably make the book much easier to navigate and more usable as a reference.

In addition, I feel that the content structure of the book could be clearer. The authors may, for example, want to adopt the division into four main parts that I use throughout this review. I also found a few minor oversights that will surely be ironed out in the next edition of the book (such as a "father" persona having no children and a missing table). Last but not least, the quality of some images needs improvement.

Conclusion

To sum up, the book by Jonathan Arnowitz, Michael Arent, and Nevin Berger is a rich and valuable source of information about prototyping software applications. It is currently the only book that provides such a broad scope with respect to the process, methods, and tools covered. Therefore, I agree with other reviewers that it is a "must read" for user interface designers and recommend delving into it. It will probably become one of the "classic" UI design resources. Nonetheless, there is still room for improvement, as I suggest in my comment.

Returning to the terms used at the very beginning of the book, I would conclude that the book is:

  • Somewhat overachieving on the process side, considering the many process steps involved and the weight that they are given in the book
  • Somewhat underachieving with respect to "hands-on" prototyping activities compared with the expectations the book raises at first glance. But, as I already mentioned, the authors have promised to deliver more content on this side
  • Most effective for beginners in the UI field who want to get an overview, orientation, and guidance for the prototyping process.
    It may be less effective for experienced prototypers, although it can still be a useful reference for them and help them to close knowledge gaps. They may even learn about new and surprising prototyping tools, as I did with respect to Adobe Acrobat.

The book may be intimidating to prototyping beginners, because it confronts – and even overwhelms – them with a twelve-step prototyping process. But rest assured: Prototyping is fun and "at the very heart" of the design process.

 

top top