Cohousing-L Mailing List: Re: Design Review

[psproefrock (psproefrock]

Having worked, until fairly recently, for an architectural firm which 
did architectural review for a couple of Traditional Neighborhood 
Design (TND) communities (as well as being the authors of the 
guidelines) I would like to say a couple things about design 
guidelines.

  Firstly, I think that there are two separate sets of issues that are 
getting intertwined here.  There are issues which pertain to original 
construction, and then there are post-construction issues (such as 
when a homowner wants to put on an addition).  Architectural 
guidelines are really post-construction (or for latter phases of 
construction if the community is being built in more than one 
phase).  Making choices and setting constraints during the initial 
design and construction is not really so much a matter of 
architectural guidelines (unless everyone has a custom unit).

  Joani had a very good point about customization raising costs for 
everyone.  The contractors can't get volume pricing (either for 
materials or for labor) when there are too few units using any given 
scheme.  Settling on a few basic packages and limiting the 
variations on those is more economical.  How much a group wants 
to trade off individuality for economy is a community decision.  If 
you want everyone to have their own custom unit, with its own style 
and character, you will end up paying for that, in professional fees 
and in construction costs.  On the other hand, making every unit 
exactly alike does not serve anyone well, and tends to produce a 
monolithic and uninteresting appearance, too.  The community 
needs to determine among themselves how much flexibilty they 
want to have in the design of their buildings, and they must realize 
that there are costs attached to these decisions.

  The communities we did design guidelines and design review for 
were far from cookie-cutter in terms of style or construction.  
Architectural guidelines need not be highly restrictive, and in my 
opinion, the best guidelines are those which allow for a lot of 
flexibility while seeking to protect the important issues.  For 
example, our guidelines stated that side loaded garages were 
preferable to garages that dominated the front elevation.  This was 
to prevent (or at least reduce) the tendency of developments to look 
like nothing more than a forest of garage doors.  If a design needed 
a front-loaded garage (sometimes lot configuration, or a plan 
someone really loved made a side-load difficult or impractical), then 
the front of the house should be closer to the sidewalk than the 
garage doors.  

  Design guidelines should (ideally) serve the interest of the 
community, and should only address issues that concern the 
community.  They should not (in my opinion) be a stylistic 
straitjacket that forces everyone to build exactly the same thing.

  Good guidelines should promote a community identity, but not at 
the expense of individuality; after all, you don't live in my house, 
and I don't live in yours.  But we do live in a community, and I think 
that expressing the community nature of the project is important.

  Many universities have an overall design aesthetic that ties the 
whole campus together.  In a college town, you can tell which are 
the school's buildings, and which are the rest of the town.  That 
doesn't mean that every dorm and classroom building looks exactly 
alike.  But there are common elements (a pallete of materials, 
perhaps a period architectural style, etc.) which help to identify the 
community as a whole.  Looking at a cohousing community in 
terms of a campus is not, I think, a bad metaphor for understanding 
what architectural guidelines should do for a community.

  Some of these ideas can be applied to both initial-construction 
and post-construction periods within a community.  But, what I 
think is most important is that the design guidelines work to further 
the ends of the community, and that that is done with minimal 
impact on design elements which do not affect the community.

Philip Proefrock
psproefrock [at] ntsource.com
(not speaking for anyone other than myself)