The design studio is the heart of architectural education. The “crown jewel” of the curriculum, it often consumes the most credits. In the two-year graduate architecture program where I teach at the University of Hartford, design studio courses account for 24 of the 64 credits, nearly 40% of the curriculum. 

The design studio’s importance is a carryover from an earlier educational model: the atelier, where students would learn by working for a practicing architect, perhaps in a master’s studio. This past model is different from how most design studios actually operate in professional education today. The atelier setting exposed emerging architects to the full range of circumstances in the process of creating a building, not just the design phase. The studio’s current prominence in education derives from the profession’s mythic culture that architects are artists first, creative people of singular vision, who practice their art in a backdrop filled with mystery. Magic happens in the studio, and the architect is the chief magician. The studio’s centrality in architectural education also means that the students who perform best in this setting are seen as the stars of the architectural program, those who can potentially raise the stature of the school through their design work. 

Many architectural educators will recognize the case I’ve laid out here, plus the drawbacks of the studio as an educational setting that should have a stronger connection to the reality of practice. At my school, I have a reputation as the instructor who prefers group projects instead of solo assignments. I have found that if you carefully pair students so that they teach each other, they end up learning not only about design, but how to work together and develop interpersonal skills that they will find useful wherever they work, in architecture or not. 

Recently I have been experimenting with a new wrinkle in the “group project” approach. A mid-semester project of five to six weeks to design a cultural center took on an entirely new dimension when I introduced a “reality check” from practice. At the project’s midpoint, the single-student designers had a “progress review.” As each student presented his or her project, a second student was assigned to take notes on the reviewers’ comments and suggestions made during the presentation. This note-taking is a common practice that allows the presenting student to focus on the review without concern to remember everything that was said. At the end of the presentations, with about two weeks left in the project before the final review, I announced to the students that the project that they had recorded notes on would now be their design project. So the notes they recorded were for them to consult, if they chose to or not.

What followed was general confusion: What? I don’t get to finish my project? I have to give my project to another student?

What followed was general confusion: What? I don’t get to finish my project? I have to give my project to another student? I will be finishing the design of another student’s project? (Projects were not directly “swapped” between two students.) I said, sure, it happens in practice all the time: you’re working on a project team and you get reassigned. That little pool house you were laboring over gets assigned to someone else. They might honor your design or take it in an entirely different direction. And I had one other requirement: each student had to keep a journal for the remainder of the project, recording what they were learning in the process, their thoughts on the nature of design authorship, their consultation (or not) with the original designer, how this experience might influence them as future architects, and comments on the pedagogical value of the project swap. 

To their credit, the students got into it, though not without the occasional grouse. Some expressed embarrassment (if not outright regret) for not having developed their projects further, and now a colleague had more work to do as a result. Working on another’s project occasioned discussions about how to use software in different ways. Transformation in authorship, one student noted, revealed itself in the mere saving of the project. “When I first received Randy’s project, I saved it as ‘Randy’s Project,’” one student reported; when he saved it again a few days later, it was as “Project 2 Progress,” embracing it and making it his own from that point on. Students reflected that, at first, their design decisions were cautious, then became more decisive. Some students consulted the original designer on changes but ultimately made design decisions that were not aligned to their “client.” Others did not consult: “What is Bryan doing with my project? No real dialogue,” read one journal entry. 

One student wrote that the swap process helped him to attain a deeper appreciation for other designers’ views, “because iteration is essential to design.” Another student reported that his discussions with the original designer about how it might change became testy. When he went forward with changes, he felt that he had finally taken authorship of the design. Another student expressed concern about altering someone else’s design: “Did I take Mike’s project in the right direction?” Some students were genuinely thrilled about the new developments their original designs were taking; others preferred not to watch. “It teaches an important lesson” about not getting too attached to a design, one student wrote. Another remarked that the project swap encouraged him to be more flexible about design—that good ideas can come from anyone on a team. 

Last week I tried the project swap out on a new group of students. They groaned at the news. They are now in the middle of it. But they are still talking to me. Sort of.

Featured image: photo by the author.