Binary Oppositions:

Are Computers Yet Aids for Design?

Column by: Scott Johnson, sven@umich.edu
Contributing author: Volker Mueller, vmueller@att.net

In the previous issue of the Quarterly, Dr. Ganapathy Mahalingam and I debated whether computers themselves would be able to design well in the foreseeable future. The topic for the current issue concerns computers aiding human designers. It is a separate goal from that considered in the previous issue, and it might be either easier or more difficult to achieve.

The question being debated is, "Are computers yet aids for design?" Arguing to the affirmative is Volker Mueller, of the firm of NBBJ in Columbus, OH and New York City. I offer the argument to the negative. Our answers to the question are dependent upon our views of design, and what we demand of design "aids." Mueller's background in practice contrasts with my own background in academia, and this is perhaps what leads us to opposing viewpoints on what design tools should do, and whether they are able to do it yet. Our opposing arguments are presented below, so that you may consider them and come to your own conclusions.

Yes:
Computers Are Aiding Design (CAAD)

Volker Mueller, vmueller@att.net

Rowe defines design as "a fundamental means of inquiry by which man realizes and gives shape to ideas of dwelling and settlement" (Rowe 1987, 1). We, then, may consider design to be a problem solving activity occurring throughout all the phases of architectural production. The category of design aids may be conceived as comprising everything that aids any part of this process. Aids range from the simplest text editors for discussion of verbalized design ideas, through basic drafting tools, to intelligent design agents.

Our firm is almost 100% computer based. This means that computers are tools in the profession, thereby satisfying the above definition of a design aid. However, this answer is too simplistic to be satisfying. A more substantiated argument requires taking a closer look at how the firm uses computers.

We use different groups of applications: groupware for e-mail and calendaring; office software; non-CAD graphics software; and CAD systems. I shall look at two of these groups as examples of applications aiding the design process.

E-mail has become our foremost mode of communication during the architectural production process. The advantages are that it has become second nature to the users, that it is asynchronous, and that it leaves an electronic paper trail. These characteristics support processes of collaborative design problem solving especially well. They afford as little application noise as possible during ideation; time for reaction to the reading; and consideration of past writings which may be quickly perused aided by search tools.

CAD systems and 3D modeling software definitely have an impact on developing, evaluating, modifying, and finally arriving at a design solution. To illustrate how this software aids design, I shall describe the activities on a recent project during a week-long charette:

First, we modeled the urban context. On the second day we started to design the massing of the project by placing and interactively manipulating volumes, adjusting their locations, footprints, and heights in shaded, interactively controlled perspective views. Team members were able to design different parts of the building's parti in parallel because our software supports file referencing very well. This enables the project team to truly work in a divide and conquer approach. It provides continuous visual feedback about the design state of the parts that other team members are designing. Normalized views (elevations, plan) allowed easy examination and adjustment of the relationships of building volumes to building limit lines and the height relationships to neighboring buildings. From the 3D model we extracted 2D information for traditional drawing sheets, allowing project team members mired in conventional design methods to provide design input, as well.

We computed total building areas based on footprint, building height, and assumed floor heights in an automated process. By the third day, a team of interior designers developed stacking diagrams, with 3D volumes describing departments, also set up for automatic area reporting. As the volumes were adjusted to fit spatial requirements, blocking solutions were developed, visually evaluated, and modified to fulfill adjacency requirements.

Concurrently, we developed the massing model into more articulate building systems by defining floor slabs, cores, structural grids, and initial designs for the building's shell. Global replacement operations allowed us to generate alternative solutions for quick iterations through evaluation loops. On the fourth day, the client proposed a different parti. With the context and area evaluation methods in place, we developed it within a day, along with a variation on the theme.

With most of these activities centered on a single model of the building, the CAD system becomes much more than a tool for design. It becomes a true aid to design.

The defining difference is in how we employ computers. If we limit them to being electronic drafting boards, they will rarely have the opportunity to aid the design of architecture. If we employ them correctly, we can allow computers to aid design.

No:
Computer-Based Tools Require Too Much Thought

Scott Johnson, sven@umich.edu

Computers are wonderful tools that aid architectural designers in many ways. They perform all kinds of analyses (structural, lighting, thermal, etc.), help produce presentation images, help create accurate and consistent construction documents, and facilitate rapid transmission of documents from one location to another. These and other features make computers invaluable for architectural designers.

But at the core of architectural design is a process of ideation, involving rapid visualization of ideas. This stage of design is typically characterized by the creation of numerous rough, often incomplete sketches. It is this stage of the design process which is most central to design, yet is the most difficult to aid.

A designer's cognitive resources are heavily taxed during this creative period (Johnson 1997). A designer needs to connect numerous thoughts together (Goldschmidt 1992), and find a single solution to numerous simultaneous problems, so that the design "comes together" as a coherent whole. Furthermore, design involves reconfiguring ideas: moving elements around, regrouping them, or changing the form of components in the design, and experiments indicate that the unaided mind is not particularly good at this (Verstijnen, Hennessy, van Leeuween, Hamel, and Goldschmidt 1998). Thus, we need what psychologist Donald Norman (1991) calls, "cognitive artifacts" to help us design. We need memory aids to help us extend our memory capacity, and visual aids to help us build new mental images.

Yet most computational "aids" to design impose their own cognitive loads. Operating the tool requires attention, taking it away from the task at hand. There are modes to keep track of and procedures to follow. Commands need to be invoked, prompts have to be interpreted, and dialog boxes demand answers to questions. Design tools wind up diverting memory, attention, and time away from the very activities they are meant to aid.

In spite of all of the technological improvements in graphics displays, processing speed, interface design, etc., there is still no substitute for a pencil. A pencil allows the architect to visualize ideas without imposing an additional cognitive load. It is perhaps the ultimate in a point-and-click interface.

The true value of a design aid can be seen in how readily we are willing to discard its output. If it takes an hour of pain-staking, thought-intensive work to get output from a computer program, we are unlikely to use it capriciously. A real design aid, on the other hand, is so quick and easy to use that we don't mind throwing away work and trying again. Using it is so trivial that we use it to visualize any of our ideas, even the ones we aren't sure of-especially the ones we aren't sure of. Consequently, a large percentage of what we visualize with the tool will be ideas that we eventually decide to discard. In a sense, the value of a design tool can be measured by the amount of garbage we produce with it.

We are making progress toward a true design tool all the time. We can now build massing models in minutes, instead of the hours it took us a decade or two ago. But it still takes longer than it takes to make a pencil sketch.

Right now, computers aid presentation, analysis, documentation, production, etc.-all the other processes that go along with design. But they don't yet adequately aid the part of the design process where most of the actual designing is done. When we have a computer-based tool that can help us rapidly visualize design ideas without taking cognitive resources away from designing, then we will have a true design tool.

My Rebuttal

Even in the broadest sense of the term "design," computer-based tools sometimes inhibit the process, rather than aid it. Some of us spend entire days mired in the asynchronicity of e-mail. But no matter how well computers aid other aspects of architectural production, they won't be the design tools we are looking for until they better aid ideation. We have not yet reached this goal.

The real-world example from the design charette provides a counter-example to this argument, but is not likely generalizable. Certain software might be able to model a high-rise office building well, and support certain kinds of design changes, but would the same software let us quickly try different room shapes, ceiling forms, and window locations; or work out strange construction details? Most people would probably use a pencil for these tasks, because it is faster and less complicated.

One mustn't fall into to trap of thinking that enthusiasm and training alone will make a tool work. A microscope makes a poor hammer, no matter how hard you try to employ it as one. Sometimes, the problem lies with the tool itself. Computers are not yet the tools we seek, though they might be soon.

Mueller's Rebuttal

The design process is a complex and ill understood process. At this point in time, the aid computers provide for it is not totally comprehensive and satisfying. There is room for improvement in all software packages. However, even the pencil has been just another design aid whose command required years of training in the architectural curriculum and during the first years in the profession. Instead of waiting for the computer aids to design to become perfect, our profession needs to acknowledge the role as design aids into which computer systems have matured over the past two decades.

Today, many architecture school graduates have interacted with computers more intensely than their predecessors interacted with pencils. These young aspiring architects create representations that aid their design thinking on computers at least as easily as with pencils on paper. Computer-literacy has replaced pencilmanship. Good design does not depend on the use of pencils anymore.

Interactively generated and evaluated computer models still may be complemented by sketches on plots, chipboard models, and other design aids. Only the combination of all possible artifacts enables us to explore the design problem as deeply as required by a thorough design solution.

Final Comments

Are computers yet design aids? Volker Mueller approaches the question from a practice-oriented standpoint, arguing that design is a multi-phase process, aided by computers in various ways throughout the process. To provide a demonstration of his point, he describes how his office utilized computers throughout a design charette.

I, on the other hand, argue from a more theoretical and developmental standpoint. I contend that at the core of design lies a process of rapid ideation, and that computer-based tools need improvement before they will aid this process in a manner that leaves cognitive resources free for design. It is left for the reader to consider both arguments and to come to his own conclusions.

"Binary Oppositions" is intended as a recurring column, a quarterly forum for the thoughtful debate of controversial issues in the area of Computer-Aided Design in architecture. It is my hope that the debate presented above will spark further thought and discussion on the issue in hallways, classrooms, and offices.

Feedback and ideas for future columns are actively encouraged. If you have comments or ideas, or if you would like to volunteer for future debates, please contact me via e-mail at

sven@umich.edu.

References

Goldschmidt, Gabriella. (1992). Criteria for design evaluation: A process-oriented paradigm. In Yehuda Kalay (Ed.), Evaluating and predicting design performance (67-77). In Yehuda Kalay (Ed.), Principles of computer-aided design series. New York, New York: John Wiley & Sons, Inc.

Johnson, Scott E. (1997). What's in a representation, why do we care, and what does it mean? Examining evidence from psychology. In. J. Peter Jordan, Bettina Mehnert, & Anton Harfmann (Eds.), ACADIA 97: Representation & design, (pp. 5-15). Cincinnati, Ohio: The Association for Computer-Aided Design in Architecture.

Norman, Donald A. (1991). Cognitive artifacts. Chap. in , ed. J. M. Carroll (Ed.), Designing interaction: Psychology at the human-computer interface. New York: Cambridge University Press.

Peter Rowe. (1987). Design thinking. Cambridge, MA: The MIT Press.

Verstijnen, I.M., J.M. Hennessy, C. van Leeuween, R. Hamel, and Gabriella Goldschmidt. (1998). Sketching and creative discovery. Design Studies 19.


Scott Johnson is a Candidate in the Doctoral Program in Architecture, Taubman College of Architecture and Urban Planning, University of Michigan. Volker Mueller is Design Technology Manager for NBBJ's Columbus, Ohio, Research Triangle Park, and New York City offices.
Back to publications by Scott Johnson
Back to curriculum vitae for Scott Johnson
Back to home page for Scott Johnson
Last update: May 13, 2003
Scott Johnson (sven@umich.edu)