Programming at an Appropriate Level

One of the things that design professionals have largely let out of their purview is an activity called programming. A "program" is a document that lays out the criteria for the success of a design project. Too often, it gets minimized to a space list and a budget; sometimes it gets expanded to include preferred or required adjacencies between spaces, and to something of the functional necessities of those spaces (electrical and Internet access, for instance). But it really ought to be something more; it ought to get at the emotional criteria we have for living with it.

I challenged a class of students tonight to develop the program for an architecture school. They had a lot of opinions about what makes a good architecture school, of course – they're experiencing one every day. But the trick is to make sure those comments land at an appropriate level. Here are the four common kinds of comments, from most vague to most specific.

Fog: "We want a building we can be proud of." Well, that's likely true, but it gives me no hint as a designer how to accomplish that. Pride, for you, might be expressed through something ostentatious, or through something immaculately detailed, or through something just plain huge. No way to know which will be most suitable.

Experiential Outcomes: "We want a building that identifies our school as something different than the other uses in the neighborhood – we don't want people to wonder what goes on inside." Now this is something that a designer might have some ideas about.

Strategies: "We ought to make the work we do in the building visible from the outside." That's a little too specific – a good designer might have any number of ways of making the identity of a school understandable that don't entail lots of ground floor windows, which might be counterindicated by other equally valid experiential desires.

Design Resolutions: "The ground floor should be glazed on two sides, from floor to ceiling." That's what you pay your designer to do in construction documents, not what the client should be thinking about early in the imagining stage.

The real trick of doing good programming work is to listen carefully, and to keep bringing the clients back to the level of experiential outcomes. "We should have a Plexiglass barrier at the reception window" is just another way of saying "I want to feel secure at my workplace." "We need another bathroom" is just another way of saying "We need to accommodate the fact that we all get ready for work and school at the same time in the morning." The designer's job is to develop strategies that seem to reach for those stated experiences, perhaps strategies that are more sophisticated and complex and wonderful than the clunky first idea that a client might start with. The longer we can keep our clients holding at the level of those experiential outcomes – up from the strategies and down from the fog – the more likely we'll be to be able to design thoughtful and successful places.

FYI, the list of outcomes we ultimately developed included (in no particular order):

• Students should be the primary focus of the buildings
• Students need a stable and claimable workplace to inhabit every time they arrive
• The circulation needs to accommodate crunch times between classes with students carrying large models
• The building should be a learning tool itself
• The surrounding neighborhood should also be a learning tool
• The building needs to accommodate the work and lifestyle needs of students who commute, and who've already been at a job all day
  
• Student ownership of the spaces – both through control and also through seeing their own work everywhere
• The building should help to foster community and repeated interactions with other students
• The administration should be "transparent" – students should know where to go to get questions answered and problems resolved, and functions should be co-located so that if their problems require administrative collaboration, the student isn't responsible for trudging all over the building and making sure that one administrator calls another one to get a resolution.

These may seem vague and unresolved. They are unresolved, but they're far from vague; my test for that is that any design student could take this list and examine her or his own physical school environment, and pretty quickly conclude whether or not (and why) the space accomplished these things. That's the kind of criteria that need to be laid out at the beginning of any project, and referred back to at every significant decision. The space list will take care of itself... it's this kind of thinking that will make the place truly satisfying.