Chief sin of architects: designing something for looks without knowing how to detail it, and putting resp for making it work on someone elseBut there are some designers who might fervently disagree, and I've started referring to their approach as naïve design. This post explores the theoretical position of naïve design and offers tips for success. Don't worry: your innocence won't be spoiled if you read on.
— Louis Medcalf (@MedcalfLouis) February 19, 2013
I've worked with more than one design director who clearly believed in the principle of naïve design. This belief wasn't always stated aloud, but I am pretty sure I did hear it explicitly in design school. Naïve design is the mindset of not allowing one's knowledge of a material's or system's limits to trammel one's creativity. Skyhooks exist in this mindset. So do marshmallow clouds of cantilevered concrete, impossibly tall towers or spindly columns, and other works of fancy like individually formed titanium panels with complex curves. The creative mind flows, and the ideas are captured, and only later does the technical mind return and begin to puzzle out how to make the resulting forms possible.
This can be a successful mindset, if the technical mind is allowed to return and is then cultivated with equal fervor. After all, this is not asking the brick to be what it wants to be; it's asking that brick to be a flower, a bird, or a star. The technical mind is tasked with making something happen that may appear impossible.
|Frank Lloyd Wright's George Barton House|
Some designers I have known only made their belief in naïve design clear by their utter disdain for technical information, especially if it came in the form "We can't do that because..." Rather than taking a meditative out-of-mind approach to ignoring known limits, a few, thankfully few, of my design directors have seen naïve design as their sole role in the design process. This meant actually defending themselves against knowledge, closing their minds to limitations.
I had a hard time understanding that when I was younger. I saw that this attitude is dangerous when it is allowed to breed mutual disrespect. However, I think that it is possible to build successful projects from naïve design beginnings if each party to the process grants the other respect and if all are working toward a common design intent.
As a specification consultant in private practice, I often won't know whether naïve design is a part of a new team's process until after we have agreed to work together. I can't afford to restrict my practice to teams that take a more holistic approach, even though that's my preferred work style. I don't have to prefer naïve design to work with it and support it, though. I'd love the chance to work on a truly fanciful building, as long as there were serious technical smarts on the team, too.
I remember a project with a broad roof terrace that got well into construction documents before someone realized that the rhythm of the ribbon windows and spandrels didn't allow for depressing the slab at the deck. The scramble to resolve this flaw would not have been so costly or convoluted if the design director had made it his business to understand the usual details for a pedestal plaza, or if he'd sought the input of a project architect with experience as soon as the massing models were complete. We raised the floor on the interior portion of that level, lowering sills and ceilings compared with the other floors, so sacrifices had to be made in furniture layouts and indirect lighting. All turned out okay, but it was a rough introduction for me to the consequences of letting naïve design go on too long.
The challenge I would set for naïve design adherents is to seek the input of your technical safety net as soon as the concept allows. Find a technical expert or two who respect your design sense and whom you can trust to give the impossible a try. Then never let them go! Share not only the design result with your team, but the thought process behind it. Seek your team's buy-in to the concepts, before respectfully asking for their input and technical challenges. Make sure you understand the changes they offer when your design defies physics or the building code. Challenge what doesn't support your intent with specifics, and be willing to share a design charette with your colleagues to find solutions. You may never feel the joy of puzzling out the impossible that technical designers relish, but it's very important to respect that ability, not just view it as their duty to your design. And see if you can allow the practical to coexist with the imagination, at least some of the time. We technical designers are designers, too, and we are just as invested in the success of the work as you are.
For technical designers, the challenge is the opposite. We may not laud the designer as a genius, but we can't become their trusted partner when we are negative and scoffing, or worse, expressing our frustration in terms like "stupid" and "irresponsible" to our teammates' faces. Rather, making an effort to understand the design intent may help us find the solution that preserves that intent while bringing the design into the reality of material and code restrictions. Ask for more sketches and descriptions, or ask to work together with the designer, if the intent hasn't made sense. We, too, can benefit from separating our practical minds from our imaginations sometimes, perhaps with painting or brainstorming or even fanciful architectural design. It may feel like "try not to think about a pink rhinoceros" at first, but it's also a freedom I associate with design school.
And managing directors, listen up! This teamwork is key to your firm's success, and both roles should ideally be filled with people of equal experience and respect within the firm. If you have naive design as part of your portfolio, you need technical designers to transform those designs into buildable, livable work, and you need to retain the best technical team players with salaries and honors that rival those of your design stars and rainmakers. Remember where you would be without them, and that your responsibility to the client demands their success.
Bringing in technical experts earlier in the design process usually improves the final result. Great post, Vivian, and much in line with current trending towards Integrated Practice Delivery. There are unfortunately few firms with technical departments strong enough to have influence early in the design process. I often wish I was brought on board earlier in my projects.ReplyDelete