Rethinking design process

What is “design process”?

Every design professional knows the answer to that question; all of them do it every day. But what are the chances that any two of them would describe it the same way?

Most architects see design process as being iterative; as making progress across a spiral of iterations. I describe this iterative process in TQM and ISO 9000 for Architects and Designers, Chapter 5.1, which you can download here.

I think part of the difficulty with getting a succinct picture of “design process” is that we are by nature and self-perspective “problem solvers”. By extension, the solution is embodied in the problem, and doesn’t exist without a problem to be solved.

Check “design” in Wikipedia; you will get a quite good discussion of the question. Wikipedia begins with a description of the “rational” model of design, but notes: “The Rational Model has been widely criticized on two primary grounds:

“Designers do not work this way – extensive empirical evidence has demonstrated that designers do not act as the rational model suggests.
“Unrealistic assumptions – goals are often unknown when a design project begins, and the requirements and constraints continue to change.”

Certainly both of these grounds are true in the built-environment design disciplines, despite determined efforts by project managers to get designers to think and work “rationally”.

Can we “manage” design?

In the 4,000-year context of the history of architecture, the concept of “Design Management” is a comparative infant – only about a decade old. Design professionals traditionally saw the design process as something that could not be “dissected” without destroying its essence. As noted above, design professionals traditionally have not mentally separated design content from design process; they see these as entwined together.

These issues are important, because, while the content of design – the combination of conditions that drive project development – are infinity varied, the processes of design, however complex, are universal. Only by separating them is it possible to create automated tools to effectively manage design process.

What rethinking is required?

If you concur with the above, and with Dana Cuff”s points in the sidebar, it seems obvious that we need to do as I suggest above: Create a model that is generally linear in problem-solving, but accepts an iterative path to get there, and which seeks universal process steps that can suitably be adapted to any project.

That is an ambitious challenge, one that is top-of-mind throughout this site and the various papers that support it.

Although there are a number of “practice management” tools available, as well as several “project management” tools (mostly for scheduling), to this point nobody has yet created a generic model for managing the design processes for the built-environment disciplines, perhaps because of the complexity of these issues.

Nevertheless, a combination of pressures of varying kinds on our design professions strongly suggest that we need such tools, now more than ever before: the time is right.

Return to Managing Design page

Dana Cuff

Dana Cuff, in Architecture: The Story of Practice, notes (p 95):

“The theory that there are problems within problems, so that each decision holds implications for earlier as well as subsequent decisions, creates an image of a nested or circular process.

“Based on what I have culled from the AIA’s literature, that organisation can be seen to promote a linear process. The sequence of phases and activities does not admit, for example, that once in design development a given process might return to schematics-like activities.

“The AIA’s project checklist … with its implied linearity, disguises what is actually a much more fluid process. The checklist also masks any indication of what these tasks might entail.

“The professional society paints the process as complex, but knowable and predictable. Design as a problem of perpetual discovery is tamed into one of time management.”