A Diagram's Work

The Vancouver House by Bjarke Ingels Group (BIG), a diagrammatic form rendered at full scale and in real life (my photo).

I participated in a review of student work this past Wednesday at the University of Oregon, one of several summer studio reviews I've sat in on this year. A faculty member and I reviewed a pair of projects—an admittedly small sample—that between them captured two versions of the same issue. One student's presentation had no site analysis or parti diagrams of any kind. The other's did, but they read as an afterthought, drawings that explained the finished design rather than ones that had helped generate it. I've noticed the same in previous reviews; even when an instructor explicitly requires process diagrams, what is pinned up still looks reverse-engineered. The problem lies in the diagrams' provenance—a reality that holds true whether they are the work of students or some of today's most celebrated firms.

Stan Allen, the architect, theorist, and former dean of Princeton's architecture program, drew a useful distinction in a 1998 essay: a diagram's job isn't to depict a building. It's to work out relationships—between program and form, between one space and another—before the building exists to depict. As Allen puts it, diagrams are "architecture's best means to engage the complexity of the real." Much of what gets called a diagram does the opposite: it reverse-engineers a graphic summary after a decision has been made, rather than helping to discover it. A generative diagram precedes the decision. It doesn't explain the building afterward; it's part of the process by which the architect finds the building's basic idea in the first place.

There's a simple test for telling the difference. Point to a particular move in the finished design and ask the student to trace it back to the diagram. Not necessarily to an identical mark, but to something in the diagram that participated in the sequence of decisions that produced it. If they can do that, the diagram probably played a generative role. If they instead begin explaining the diagram in terms of the finished building, the odds are good that the diagram came later. A generative diagram doesn't have to predict the finished design, only to have been capable of changing its direction.

Early design diagram for the VA Roseburg Protective Care Unit. The courtyard organization survived; the entry gesture did not.

The old sketch above passes this test, with qualifications. I drew it during my earliest analyses for the design of the VA Roseburg Protective Care Unit, as I attempted to match site, program, and intent. (I covered this project's design process in my "A Case Study" series of posts.) It's clearly rough: hatched masses standing in for building volumes, a loose unhatched void at the center indicating a courtyard, and an arrow driving in from outside the frame toward one corner.

The courtyard organization held. It became the wrapped, mirrored heart of the finished design, anchored by a huge mimosa tree that I likened to the proverbial Tree of Life. The arrow, on the other hand, didn't hold. It was a stand-in for a real, unresolved question: how to control entry into the secure courtyard. What ultimately emerged wasn't a refinement of the arrow's gesture. It became an entry pavilion, akin to the Propylaea at the Acropolis.

Site plan for the VA Roseburg Protective Care Unit.

That's the important distinction. The diagram didn't predict the building. It put a problem into play while the design was still unsettled enough for the problem to matter. One part of the sketch survived almost intact; another led somewhere I hadn't anticipated. Both were useful because they helped determine what came next.

This tension between diagrammatic exploration and graphic presentation persists in contemporary practice. Bjarke Ingels has described how his firm, BIG, uses diagrams to track the reasoning behind design decisions, a practice he developed in part while working under Rem Koolhaas at OMA. MVRDV's Farmax, published around the same period as Allen's essay, made particularly explicit use of diagrams as instruments of form-finding.  

BIG's series of conceptual diagrams for their Vancouver House project (source: htttps://big.dk/projects/vancouver-house-missing-pictures-7130)  

Yet, there remains a persistent ambiguity in architectural representation: a diagram can document a process, or it can be made to look as though a process existed. Critics have sometimes read BIG's diagrams less as records of discovery than as clever post-rationalization of forms arrived at by other means. The distinction matters because a diagram can be perfectly convincing as a graphic artifact while having had no meaningful role in producing the design.

AI makes that distinction more consequential. Current tools can generate massing alternatives, test code and zoning conditions, manipulate models, and produce images that would once have required considerable effort. Those capabilities may become useful parts of conceptual design. The more immediate problem is simpler: AI can also produce polished, diagram-shaped images on demand. It becomes all too easy to manufacture the appearance of a rigorous design process after the fact.

The issue isn't whether an AI-generated diagram is legitimate because a person didn't draw it by hand. A computer-generated diagram can be every bit as generative as a pencil sketch if it helps identify a consequential relationship, tests an idea, or changes the direction of the design. What matters is what the diagram does in the sequence of thought. A diagram that merely gives graphic form to a conclusion reached some other way is still an afterthought, regardless of who, or what, made it.

Generative diagram by MVRDV for The Modernist, a mixed-use project in Rotterdam (image source: https://www.mvrdv.com/projects/308/the-modernist)  

This is also why a diagram's graphic appearance can be misleading. Arrows, bubbles, hatching, color coding, and other conventions can make a drawing look diagrammatic without telling us anything about its role in the design process. Resembling a diagram isn't the same as having done a diagram's work.

The student who left diagrams out of the presentation wasn't hiding anything, and the one whose diagrams read as afterthoughts wasn't trying to pass off invented process as real. Both, I suspect, simply hadn't yet learned the purpose of diagramming during the early phase of project conceptualization. That's a lesson AI tools may make easier to skip, in a studio or in a firm, because they can cleanly simulate the appearance of analysis without requiring the heavy cognitive lift of the analysis itself.

The afterthought diagram is the more instructive case because it looks like it's doing a job it isn't. Whatever insight it might have delivered—what relationship was worth testing, which constraint should organize the plan—was available only while the design was still unsettled enough to need testing. It can still look flawless on a presentation board, but what it ultimately lacks is a place in the sequence where it still had the power to change the outcome.