The Rational Model of Design
The Design of Design: Essays from a Computer Scientist
Models of design
Frederick P. Brooks, who wrote the classic The Mythical Man-Month
Systematic design excluding intuition yields pedestrian follow-ons and knock-offs; intuitive design without system yields flawed fancies. How to weld intuition and systematic approach? How to grow as a designer? How to function in a design team?
The rational model of design
Brooks believes that the the rational model of design is fundamentally wrong. He defines the rational model as having a goal, desiderata (secondary goals or requirements), a utility function (a way to weigh various desiderata in terms of goodness), and constraints (frequently time, budget, or other resource). This approach is commonly used in many engineering disciplines.
The rational model assumes a single design tree of decisions which must be traversed in a linear manner to find the best design hiding among the leaves. As a designer works through each successive decision, the final design comes into focus as various alternatives are eliminated on the way to the final goal. The designer can back-track if a particular line of design decisions dead-end in an unsatisfactory outcome. The rational model is manifested in the Waterfall software development process. However, for large and/or complex design projects, design decisions are frequently not limited to design alternatives, but spawn entirely new designs, adding new dimensions to the tree.
Design trees
In an essay devoted to exploring the design tree for the addition of a new wing to his house, Brooks discovers two prominent themes within the book: design uncovers new requirements and designs. Again, Brooks arrives at the conclusion that the process of design is more like exploratory creation than elimination of a known set of alternatives. In the video below, Brooks mentions that his attempts to document a tree structure for decisions related to his house remodel have proved to be much more difficult than even he anticipated.
the hardest part of design is deciding what to design.
The primary flaw in the rational model is that it is not possible to know the design goal in advance. This assumption underpins much thinking in requirements methodologies. If the goal is not known at the outset, then it is not possible to use a single decision tree to arrive at a final design. Moreover, it is typically not feasible to articulate every single design alternative within a clean decision tree.
Brooks asserts that by eliciting requirements, the design becomes clear. This is in opposition to the view that all requirements can be known at the outset and the design phase is meant simply to translate those requirements into an implementable specification. He believes that design cannot be separated from requirements. In the book and video below he relates a personal experience as a programmer which led him to understand that implementing a set of known requirements allows the final design to be illuminated through successive iterations of refined requirements.
Predictability and great design are not friends.
Brooks also finds fault in the rational model because “it is a good way to get follow-on products” rather than disruptive or innovative offerings. This model of design is good at producing “functional enrichment” but is not based in an iterative or exploratory approach to requirements and design which is required for completely new products and services.
The co-evolutionary model
An alternative to the rational/waterfall model is the co-evolutionary model (Maher and Poon, 1996). The co-evolutionary design model is fundamentally exploratory and acknowledges that as each plateau is reached, a new vista appears, and with it a new perspective on the problems, requirements, and eventual solution. The design team cycles through resolving a problem, evaluating the solution, and then discovering a new set of problems, requirements, goals, and constraints. The movement and interaction between the problems and solutions refines the final design and the team’s understanding of the problem domain. The perfect design is never reached, rather a more in depth understanding is gained as assertions are tested against business and customer needs. As opposed to the rational model of design, the co-evolutionary model explicitly identifies the ongoing relationship between requirements and design. It is not founded on the notion that requirements are fixed and the requirements process has a discrete end-point which occurs prior to design and development. The design team’s understanding of the problem itself deepens as prototypes and solutions are developed.
Great designs come from great designers, not from great design processes.
This book covers several overlapping aspects of complex systems design: models of the design process, how design is different today than it was in the past, and how individuals contribute to great designs. Brooks is a proponent of single individuals or pairs of individuals creating designs over large teams. He believes that the integrity of the design concept (the overall architectural model of the object under design) is the most important factor for great designs. Because teams today are distributed, the process of creating, communicating, and evolving the design concept becomes more difficult.
Separation of the design from production and usage
The essay titled “The Divorce of Design” explores the consequences of the separation of the designer from production and usage. This theme runs throughout the book–previous generations of inventor/designers who made products versus current design teams which consist of specialists who are separated from complex chains of manufacturing and component production. This change results in many of the questions Brooks poses: how can designers maintain close contact with the beneficiaries of their design?, how can individual specialists collaborate to create a coherent design that meets the needs of the end-user?, how can great designers be trained and found?
No amount of process improvement can raise the ceiling of the community’s practice. Great designs do not come from great processes; they come from talented people doing hard work.
He extends his thinking about individual designers by thinking about product processes which often surround design processes. He finds the approvals and stages associated with product processes to be a hindrance to innovation. Product processes are designed to reduce variation and exceptions; however, innovations are by definition exceptions so they do not usually thrive in a process-centric environment.
The essays in the book covers many design topics including requirements, constraints, aesthetics and style in technical design, why expert designers make mistakes, and how to effectively use previous designs. Brooks has been in the computer industry since the 1950’s and brings an interesting perspective on design–many of his examples are from IBM mainframe operating systems (OS/360, JCL) of the 1960’s and 1970’s. He ends the book with a set of design case studies from mechanical engineering, residential architecture, and computer systems. The case studies provide requirements, constraints, decisions and the final design in order to illustrate the complex and dynamic nature of the design process across various disciplines (one of the questions he poses in the book is whether there can be a universal design method that exists independently of a subject matter domain).
Critique of the rational model of design
In the first half of this video, Brooks explains his critique of the rational model of design. He is challenged by several students on a number of his points, which he doesn’t fully address, but it’s an interesting presentation nevertheless. The second half of the video corresponds to the second part of the book which addresses team design and collaboration, which Brooks believes to be characteristics of 20th and 21st century design (as opposed to 19th century design).
