Binary Oppositions:
Should Designers Learn to Think Differently in Order to Better Utilize Digital Design Tools?

The development of information technology and its application to design disciplines has changed how buildings are described and even how they are built. Engineers, architects, contractors, and other parties often exchange files instead of paper drawings, and manufacturers can be sent numeric data to guide the fabrication of customized building components. The tools of the trade, even the things possible in the trade, are changing. This brings up the issue of how best to utilize this emerging technology. Should we mold this technology to fit the tasks and concepts we have in mind, or should we learn new ways of thinking about architecture and our role as architects? Do we need to get used to thinking in terms of RGB values, external file references, geometric transformations, and paper space vs. model space? In short, should designers learn to think differently in order to better utilize digital design tools?

Arguing to the affirmative is Brian Johnson, of the University of Washington. I offer the argument to the negative. These arguments and our respective rebuttals are presented below, so that you may consider them and form your own opinions on the topic.

Yes: Designers Should Think Differently in Order to Better Utilize Digital Design Tools. Brian Johnson, brj@u.washington.edu After every major addition to the palette of options available to architects, buildings have changed. This is true of both the development of new materials, such as iron, steel, concrete, and glass, and new technologies, such as electrical lighting, elevators, and air conditioning. While the initial impacts are often cosmetic changes in material alone, such as substituting cast iron for stone or timber while retaining the forms, the full potential of the technological change is not felt until designers begin to explore the ways in which the new technology allows them to "Think Different" about buildings. At that point architectural expression often undergoes a significant change, at levels ranging from tectonics to building types. Information technologies (IT) are no different. The initial application of computing in architecture has been one of substitution-CAD drafting replacing hand drafting. In most offices, until recently, this has been so literal that drawing sheets and computer files have been thought of in a 1:1 relationship. When addressed at this level, the question of "should" directs attention to the user-interface and issues of software design. While important and relevant, this misses the point of the new technology. Exploration of the architecture enabled by information technology is really just beginning, pioneered by the likes of Asymptote Design and Frank Gehry. These designers use IT to extend the design paradigm of traditional architecture into the manufacturing process. Design expands from a process of setting geometry, assembling pre-existing building systems and specifying finishes, growing to take on the specification and design of the systems themselves, often working with the expertise of the manufacturer. This approach offers the designer greater morphological freedom and it may reverse the erosion of the scope of professional services by expanding the province of the architect. Even within the "minor" application of information technology to drawing production, I believe that it is often appropriate and desirable to "Think Different" in order to utilize digital tools to their best advantage. It is not necessary to think differently, but it has beneficial results. This is because the recasting of the process into a digital framework creates "digital affordances" or opportunities that are not found in the traditional circumstance. Given drawings as a form of representation, the unique opportunities, or affordances offered by CAD systems are important. If we do not learn to think with and about these new affordances, we will miss out. For example, CAD presents many opportunities to think digitally, starting with the transformation of "pencil marks" on paper into abstract "graphic objects." Where hand drafters construct drawings line by line, deriving little benefit from repetitive elements, CAD drafters have the opportunity to replicate those portions of the drawing. This can be done in "traditional" and "digital" ways. Following the traditional mindset a user might simply "copy and paste" the repetitive graphic as needed. The digital mindset takes advantage of a uniquely digital affordance: the "clump" (AutoCAD block) and instance (block insertion). A clump is a named collection of primitive elements. Most students grasp it easily because it sounds like the plastic templates hand-drafters use to reproduce patterns of lines. However, the related concept of an instance, with the implied one-to-many dependency relationship, presents a uniquely digital affordance-it lacks a hand-drawing analogue. As a result, understanding the difference between multiple insertions of an AutoCAD block and repeated replication of the block's graphics is often quite challenging for students. Before they can use this feature to simplify editing, deliver alternative design schemes, exploit data management opportunities and minimize file size, they must learn to think about what they are doing in a different way. They should learn to do so, not because the tool demands it, but because the job does.

No: Software Should Change to Fit the Way Architects Think Scott Johnson, sven@umich.edu While some architects advocate changing how we think about our work in order to use computers, interface experts tend to disagree with that opinion. Donald Norman (1990b, 217), for instance, writes, "Make the task dominate; make the tools invisible." The argument that architects should "think differently about architecture" often underestimates the value of the patterns of thinking that architects have developed over the course of centuries. We have developed a myriad of mental rules and processes for design. These rules and processes are valuable; we could not design as well, for instance, if we changed our thought processes, and tried to work out details before broad organizational problems. Similarly, we have developed mental libraries of architectural "elements" that are replete with functional and symbolic associations. Our concept of a wall isn't just a geometric description; it has space-defining, symbolic, thermal, lighting, acoustic, structural, financial, and other connotations, which are vitally important in architectural decision-making. We have developed types of drawings and models to help us readily see certain kinds of relationships and solve certain types of problems. If we change the kinds of views we use, we change the kind of information we have access to. We have developed ways of organizing our projects to fit our office labor pools, project timelines, and legal obligations, and to mesh with the practices of other professionals we work with (clients, engineers, contractors, inspectors, etc.). These project management practices can't be changed without extensive repercussions. We've taken centuries to develop these ways of thinking about designs and about designing. They are what allow us to design. They shouldn't be changed without good reason. Furthermore, changing the way we think is easier said than done. Psychologist John Hayes (1989, 293-298) notes that it usually takes at least a decade of intensive study to achieve expertise in a field, due to the large number of mental "patterns" that must be learned. And once we learn to think one way, it can be very difficult to un-learn it. Mental processes are often so automatized that we find ourselves following them unintentionally (Norman 1990a, 106-107). Previously learned information can significantly interfere with trying to learn new information (Best 1989, 227-230). This is not to say that to say that architects can't ever learn new ways of thinking about designs and designing, or that we shouldn't. The key is to change deeply rooted thought processes only when the benefits outweigh the costs. We must be careful to distinguish between thinking differently to do better/more efficient work, and thinking differently to use a tool. The first is admirable, but the second is the sign of a faulty tool. It is usually better to adjust the tool to fit the user, rather than trying to adjust the user to fit the tool. It might be argued that it is idealistic to wait for software to adjust to architects, while it is pragmatic to adjust our thinking to fit the tools now available. Yet, what is idealistic today is likely to be pragmatic tomorrow. Decades ago, an architect using a computer might have had to think about architecture in terms of command scripts for generating forms, or files containing hundreds of comma-separated integer node numbers and real number coordinates. Then graphical entities and their attributes, like lines, layers, insertion points and scale factors, became the norm. Now the trend is toward more "architectural" elements and attributes: walls and windows, wall types and sill heights. So, not only should computers change to fit the way architects think (instead of vice versa), computers are already well on their way to doing it.

My Rebuttal The "point" of using computers in the design process is to improve the process and the product of design. Computers do this by letting us use our architectural knowledge and experience in better ways. But certain realities of how we think must be acknowledged. We can't reorganize our thought processes or learn to think of architecture in different terms whenever new software comes out. Certainly, a user who understands concepts like instantiation will be able to make better use of today's software than a user who doesn't. Sometimes, this "thinking different" affords worthwhile advantages. Often, however, it is merely a way of coping with an interface that interferes with our knowledge and experience. Arguably, instantiation itself is not a new concept, but rather, an old one, for which there wasn't a tool until drafting software allowed symbols and symbol redefinition. This illustrates what may be the ideal role for new technology: letting us see things we always wanted to see, work in ways we always wanted to work, and build things we always wanted to build, but never could before. Information technology can open new possibilities for us without forcing us into unfamiliar processes, elements, views, and practices that are ill-suited for architectural design.

Brian Johnson's Rebuttal The statement against the proposition assumes that "current practice" is successful. This flies in the face of the erosion of architectural responsibilities as facilities managers, construction managers, and design-build firms encroach on traditional practice. It is further contradicted by the costs of repairing "information errors" (perhaps up to 20% of construction budgets). While the "patterns" of traditional practice may have met the design needs of an earlier construction industry, they have not been adequate to the complexities of modern building. Another assumption is that the practice patterns supported by existing software-the production of drawings-is the appropriate domain of computing, needing only to be improved. Yes, architects create drawings, but drawings are a means to an end, not the end itself. Architects think about a project in many ways: as an economic undertaking; as attitudes about materials, form, axes, Nature, and Man; as walls, windows, doors and floors deployed to meet human needs; and as an assembly of details, calculations, and choices which represent our best guesses to meet a budget. There are many opportunities in this mix where computing might aid design, some of them may be more successful than drawings. Application of computing to drawing production, representing the largest portion of the Architect's fees, should be no surprise and the relative simplicity of addressing the drawing manipulation task makes software sense. These are first steps. In taking the next steps architects will necessarily encounter new ways of completing familiar tasks. Those who make the best use of these tools will do so by thinking differently.

Final Comments

"Binary Oppositions" is 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 lead to further reflection on the issue and spark informed discussions 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

Hayes, John R. (1989). The complete problem solver. Hillsdale, New Jersey: Lawrence Erlbaum Associates.

Norman, Donald A. (1990a). The design of everyday things. Originally published as The psychology of everyday things, New York, New York: Basic Books Inc., 1988; reprint New York: Doubleday (page references are to reprint edition).

Norman, Donald A. (1990b). Why interfaces don't work. In Brenda Laurel (Ed.), The art of human-computer interface design, (209-218). Reading, Massachusetts: Addison Wesley Publishing Company, Inc.