Book Review: The Design of Design: Essays from a Computer Scientist

Collaboration and Telecollaboration

Brooks examines how much design work takes place on teams of more than two people and presents convincing evidence that, while there are benefits to breaking up design tasks—and particularly, for requirements capture—the design can lose its conceptual integrity as a result. Crucially, Brooks argues that the design of a user interface must be “tightly controlled by one mind.” Part of his rationale appears to be that, if there is no one person on the design team who understands the user interface completely, it is unlikely that user’s will understand the user interface, and this view has some merit. However, Brooks is strongly in favor of two-person teams, which he argues have different dynamics to larger teams, helping to maintain the conceptual integrity of a design.

These days, many organizations consider telecollaboration to be business as usual. Brooks takes a step back and looks at what is necessary to make it work effectively: Some face?to?face time and clean interfaces between different components are essential for any remotely distributed team to collaborate effectively. Telecollaboration isn’t easy.

When I was working for BT Labs in 1995, there were predictions that telecollaboration would massively reduce the need for people to be colocated to work together. We’re now 15 years on, and the human factor—not the technology—is still the key factor limiting effective telecollaboration. Applying more sophisticated technology is not enough. Understanding the working styles, communication styles, and idiosyncrasies of other organizations and people with whom we work is vital for effective collaboration, but people still largely overlook the need for this.

Design Perspectives

In the chapter “Rationalism Versus Empiricism in Design,” Brooks reinforces the need for an empirical approach to design: testing and iteration are vital to producing an effective design. This is equally true for both UX designers and system architects.

Brooks raises an interesting point: software architecture is the only design domain that has attempted to prove correctness through formal methods. These methods are less rigorous than mathematical correctness proofs, but the approach Cleanroom Software Engineering has taken is perhaps more applicable to user experience. Here, each aspect of a design receives intense group scrutiny, with the designer explaining the rationale behind the design as the group challenges his assumptions and arguments.

Brooks is a strong advocate of user models; the chapter “User Models: Better Wrong Than Vague” captures his attitude succinctly. While he doesn’t describe user models in the form of personas, the essential approach and details are the same.

Brooks explores the value of design constraints as a way of reducing the design space within which we need to search for a solution and stresses the need to challenge and understand which design constraints are real and which are obsolete, misperceptions, or intentionally artificial. Many nondesigners find the concept of a problem with no or few design constraints being harder to solve than one with more design constraints to be counterintuitive, but Brooks makes an excellent point when he notes that, by the same token, a problem with no design constraints has no criteria for excellence. Brooks states:

“When you specify something to be designed, tell what properties you need, not how they are to be achieved.”—Frederick P. Brooks, Jr.

Particularly with user experience, clients often confuse a requirement with an implementation; it is reassuring to see that we are not alone in recognizing and experiencing this!

For those with a nontechnical background, a chapter on “Esthetics [sic] and Style in Technical Design” may seem to be a contradiction in terms, but Brooks does an excellent job of describing how many of the same aesthetic principles apply to both visual design and technical design. In this chapter, he provides a simple prescription for achieving good design style that applies equally well to user experience:

• Study other designers’ styles intentionally. Practice working in another’s style. This forces attention to detail and explicit thinking.
• Make conscious judgments. Understand what you like and why.
• Practice. Practice. Practice. This is the only way to develop expertise.
• Revise your designs. Look for stylistic inconsistencies.
• Choose designers carefully. Seek designers who have clear styles and good taste, as demonstrated by their previous works.

Brooks expands on this theme in Chapters 13–15, which I would argue are particularly useful for UX designers who are seeking to grow professionally. These chapters look at how designers can develop by studying the strengths and weaknesses of exemplars in their field, how expert designers go wrong, and the types of problems that result from designers becoming divorced from implementers and users. Chapters 19 and 20 continue this theme: Brooks looks at how best to support great designers, particularly in the context of a corporate design process. As he puts it:

“The trick is to hold process off long enough to permit great design to occur, so that the lesser issues can be debated once the great design is on the table—rather than smothering it in the cradle.”—Frederick P. Brooks, Jr.

Brooks takes pains to make it clear that great design—and great designers—can flourish only in a supportive environment and credits the manager of one of the greatest designers he’s known personally for this understanding.

Trips Through Design Spaces: Case Studies

I found the last part of the book harder going, particularly where Brooks uses building architecture as a way of illustrating the design process. This may partly be attributable to the medium of communication he was using—I felt this material would work better in a classroom setting—but this may equally be a failure of understanding on my part. I found his more technical examples easier to follow, but this might not be true for everyone.

Conclusion

While Brooks’s background is in software architecture, many of his views are wholly congruent with those of the UX community: the need for user models, the need to iterate design through prototypes, and elegance in design. In writing this book, he highlights how the similarities between different design disciplines far outweigh their differences.

This book is a collection of independent essays. Thus, it’s very easy for a reader to just dip into one of the book’s essays rather than having to work through the entire book from beginning to end. Brooks uses a lot of real?world examples to illustrate the points he’s making. Quotations and illustrations break up the text effectively.

This isn’t a book that would appeal to all designers: Brooks is a computer scientist by training and many of his examples draw on this. Brooks is not above providing examples of projects where something developed under his supervision went wrong to illustrate a point—such as when he talks about “The Worst Computer Language Ever.”

On the whole, designers who already have a lot of experience will understand the concepts the book discusses—so learn more from it than novices might. There are certain chapters—for example those looking at how to support great design most effectively and the role of design process—that deserve the attention of project managers and others responsible for creating contexts that are conducive to design excellence.