Architecture and the Lost Art of Drawing

I was trained as an architect and worked in the field for over a decade. Drawing had and still has an important role to play in all of my creative processes. However...

It's all to easy to put drawing on too high a pedestal, and Michael Graves is possibly the best example of the dangers of doing so. His drawings are pleasing: humourous lines, stimulating juxtapositions of shape and colour. But they are not architecture, and Graves' focus on the art of drawing has made him a terrible architect.

Architecture is not experienced in two dimensions: it is experienced in four. It is only ever seen in perspective and in time. What it looks like as a two dimensional projection is irrelevant to the actual embodied experience of architecture. People who spend too much time immersed in drawings tend to lose sight of this.

Moreover, architecture is not just a visual. It also creates a tactile, acoustic, and olfactory environment. It conveys ambient and radient temperatures, and channels the movement of air. It exists within diurnal and seasonal and social cycles, continually changing. Drawing can represent NONE of this, and the architect who approaches their art purely through drawing will lose sight of these facts. Graves certainly has. His buildings -- rendered in three dimensions, out of actual materials on actual sites -- are tacky-feeling, hollow-sounding monstrosities: dank where they should be airy, glaring where they should be shady, completely disconnected from their environments, and not remotely conducive to work or socialisation or rest or any other purpose that humans might want to put a building towards.

But hell, they look great on paper, and that's what counts, right?

The truth is that architecture is a difficult art, because it cannot be iteratively developed and refined in the same way as other arts. If you're a painter, you paint; if you're a musician, you play music until your fingers bleed. But if you're an architect, you develop your art through indirect representation. Through virtual reality, as it were. And drawing is just another form of virtual reality -- better at representing some aspects of architecture (emotional characteristics of a design, for example) -- and almost incapable of representing others (four-dimensionality, acoustics, tactility, air). It should be quite an important form of representation within the architect's toolkit, but if it's too highly prioritised, then you'll end up as bad an architect as Michael Graves. A well-balanced architect should develop all forms of representation available to them -- both visual and non-visual -- if they are going to fully grasp all aspects of their art.

As much as we like to discuss paperlessness, the simple act of taking a pen or brush to paper or other surfaces to record visual ideas is too widely applicable to be really replaced. Working with stainless steel kitchen equipment fabricators and installers, you see ideas faxed from office to office, scrawled over, faxed back, scanned, emailed printed out, marked up again, faxed over again, and finally turned into a custom table to fit perfectly in one restaurant kitchen.

Integrating that kind of workflow will be essential for groups looking to automate construction, such as PlanGrid. Ideally, you would be able to print out a CAD drawing, draw some extra lines (or measurements) on it, scan it, and the software would somehow import the hand-drawn lines into the CAD file.

(In some ways, this situation is mirrored in sheet music - the beautiful instrumental melodies you hear are often played from sheets that have been copied, written on, erased, written again, copied after that, and written on in pen. I'm surprised nobody's developed a sheet music app.)

When I get truly stuck on a software problem I leave the keyboard, go to a coffee shop, and draw-diagram-doodle a solution.

Architect in the making here.

I was expecting Graves's article to be some form of luddism judged by the title, but after reading it I assume that it is linkbait that was added by the editors. In fact, I don't see anything overly negative that Graves said. He correctly points out the reality: that there are certain parts of a ‘creative’ work flow that are not addressed by any software at this moment. CAD has it's place and has made drafting easier, but honestly drafting is not where the value or enjoyment lies in an architect's day-to-day. The term "CAD monkey" exists for a reason.

There is a very important distinction that Graves points out: “referential sketch”, “preparatory study” and “definitive drawing”. Each of these is very different and has different requirements.

I used to dream of something like a unified work flow for this stuff, where you could do everything in one, well integrated (digital) ecosystem. It does not exist, not for architecture, and I suspect it's mainly because an architects requirements at the first stages are almost the inverse of what they are at last stages. Compare the properties of a sketch to construction documents: in the former you don't want any friction and keep things abstract and detached from technical requirements, whereas the latter has to stand up. An analogy would be going from a fashion designer's ‘inspiration board’ to instructions for making the clothes.

The first stages are rough, contradictory, abstract, idiosyncratic. Things that software is not very good at being. I feel that especially the last word on that list is crucial, since there are some people (like me) who don't even draw that much, I much prefer to work with text and more abstract references in the stage that Graves described as "referential sketch".

CAD has addressed the points where communication standards exist, but nobody brainstorms and researches in the same way so it's difficult to build a tool around that. As an example: another architect, Steven Holl, travels frequently. He does small (A5-ish) watercolours with a pocket set, takes a picture of it with his iPhone and sends it to his studio in NY. His staff knows him enough now to understand them and can use them to develop their projects.

The people who wrote "How To Design Classes" seem to think the same thing:

"Diagrams Draw them by hand. Diagrams are the programmer’s doodling language. Using a tool that draws them for you from the existing code defeats the purpose. Assigning students to do so defeats the purpose of learning to doodle."

Its the first statement in the book.