Skip to content
Categories:

Architecture Myths #29: The Problem

Post date:
Author:

Last year I wrote a foreword for a book on the design process. I won’t be spilling any beans by saying that, however you look at it, it breaks down to the three sub-processes of 1) Identify/define the problem, 2) Decide what buildings, concepts, ideas, tools or techniques you think will be of use in solving it, and 3) Stir it all together and come up with the design solution. This is often restated as Define–Analyse–Synthesise but many of the more complex breakdowns merely elaborate on the same three-part structure.

Even the parametric design processes conform to this structure even though 1) the identification and definition of the problem depends on what is (or must claim is) important to you, 2) the techniques you use will be the ones you are set on using, and 3) this means contriving the parameters to produce some iteration that will do the job as you defined it and that will somehow and at the same time fit the job you were tasked with.

But whether simple or complex, this thing called The Design Process has a few problems, the most elephanty of which is “does calling something a process mean it is one?” Was there always this thing called a design process or is the word process and the use of terms such as inputs and outputs merely an historic consequence of design seeking to align itself with industry? [Probably.] Later, we began to express the design process in terms of variables and factors because we thought they were more inclusive of social and environmental concerns but all this was was to align with the terminology of computing rather than that of industry. There’s a pattern.

Later still, we have the inputs to parametric design as whatever parameters are deemed useful and/or important as well as the values assigned to what is assumed to be a realistic mathematical model (i.e,. an algorithm) of them and their interdependencies. Whether all this is ingenuous or deliberately skewed in anticipation of a certain design output we will never know.

Given all these uncertainties, it’s amazing anything ever gets built. Somehow, we start with whatever we know or think we know, and we end with a building. Like most things, this thing called the design process has a beginning and an end and it’s probably okay to call it a design process, identify three parts of it and proceed to give them names as long as we recognize that

  1. Identifying a problem already assumes it is something an architectural design can solve. Even using the word solve implies a causal relationship between the two as, incidentally, does the word process.
  2. The techniques (or, if you must, examples) you think might be of use in helping you solve that problem need to be up to the task and the right things need to be learned from them. In universities we use the terms “case studies” and “precedents” and they are supposed to function in the design process in the design studio as substitutes for knowledge and experience. That’s all I’ll say for now. I’ll talk more about these in the next post in this series.
  3. The problem with the third part, Synthesis, is that nobody knows what it is or how it works and so we use words like inspiration and creativity to give a name to this part of the process that not only don’t we understand it, we then proceed to assume it must be something truly magical and special because we don’t understand it. Iffy. At lest with The Digestive Process or The Bessemer Process for steel production, every stage is known. With The Design Process, we don’t really know anything about what happens in this final stage we call synthesis and so we talk about it as a “black box” in order for it to still fit our model of it as a process. It’s not wrong to do this because it implies something happens inside but we just don’t yet know the actual mechanism by which it does. However, it is wrong to call this mechanism “creativity” and claim it’s beyond explanation merely because we can’t explain it.

So, this is the outline of the 1-2-3 posts in this series that will deal, in sequence, this thing we call The Design Process. First,

The Problem

The problem has to be something an architectural design or, if you want to be grand, that architectural intelligence, can solve.

I don’t want to introduce new terminology into an already overcrowded lexicon, so my simple working definition of architectural intelligence is the ability to understand and solve the spatial dimensions of certain problems. I’m aware of what this includes and what it excludes and it all hinges on what you call a problem. For example, Chernikov produced a wonderful set of drawings that were very architectural apart from them not solving any particular problem. I could say the same of Sant’Elia.


More usually, a client has something in mind and an architect produces a design that satisfies those needs and at the same time leverage the client’s project for their own publicity and marketing ends. How the client and how the architect see the problem aren’t necessarily in conflict because a client can choose an architect by their media profile in expectation of some value whether quantifiable or not.

Similarly, an ambitious student will take the instructor’s problem and solve it in a way that’s more likely to be complex than simple or that they think will look better in their folio. This may or may not be a clever thing to do in the case of the larger commercial practices. If a student’s marketing of a project is better than the actual project, then they may well find themselves back in their home country as business development manager. I’m usually against students deciding their own project, site and program but only because that’s not how it works.

Last semester the students were asked to think about cities and their problems and to propose an architectural solution. It was big and daunting stuff so I reduced it to three approaches (even though this itself is a design decision).

1. A refinement, reorganization or redesign of one part or aspect of a city. 

The proposal below suggests Manhattan could do with a re-zoning but conventional urban regeneration projects are also examples of this approach, as are sustainable cities, smart cities and resilient cities.

I’m not saying this is a good example, merely that the success of the solution depends on how the problem is framed. Now that semester is over, I can see how the entire design process can be reverse engineered to make the solution appear the inevitable outcome. This probably happens more often than we are aware of.

2. An urban module that could be repeated across an entire city

The objective of this approach was to provide a new template for city living, and that can be repeated indefinitely across the city. This Mario Chiattone project takes a much larger mixed use building as its basic urban unit. Anything truly archetypal will have obvious and irresistible benefits.

3. Design a city on the basis of a single premise. 

This third option was a “What if?” scenario. What would a city be like if we had no more elevators? What if we couldn’t build in concrete and steel anymore? What if Covid never goes away? What if all retail stores disappeared from the city and only hairdressers and restaurants remained?

Submission had to be in the form of a blog post structured according to the three stages of the design process, and with attachments and downloads as appropriate. In this first stage, I wanted students to be absolutely clear about the problem they were solving, and to commit to it in writing. The project outline had sufficient scope for personal interests to show but, at this stage, all that was required was for students to indicate what kind of problems they were interested in solving, not how they intended to solve them. I produced the following as a worked example for them to follow.


SETTING THE PROBLEM

The problem is always the same: How to enable people to live at a high density yet still provide them with adequate daylight and ventilation, and a sense of belonging while ensuring privacy but not isolation. Ludwig Mies van Der Rohe’s 1953 Lake Shore Drive Apartments in Chicago are typical 20th century apartment buildings in treating residential space as if it were hotel rooms with doors opening off of internal corridors that are artificially lit and ventilated.

Ludwig Mies van der Rohe, Lake Shore Drive Apartments (as-built and marketed), Chicago, 1949–1951

This configuration maximizes external window area and also maximizes the ratio of sellable space to unsellable space. The rectangular floor plate encloses maximum volume with minimal external wall. The building is also typical in that the apartment front doors form a communal-private boundary that isolates the two sides from each other. Casual interaction between occupants is limited to elevator lobbies and corridors. Inside the apartments, windows look away from the building and the building behind disappears, along with any sense there might have been of belonging to some kind of community, albeit a vertical one.

Windows are necessary for habitable rooms yet, in the Western world at least, aren’t thought essential for non-habitable rooms and so kitchens and bathrooms cluster at the centre of the typical floor, enabling all window wall to be used to add value to habitable rooms. The amount of window area in apartment buildings has risen steadily and is regularly over 70% of exterior wall surface and can reach as much as 100%.

The other problem inherent to this “hotel corridor” configuration is dependency upon mechanical systems and the energy they require to not only to light and ventilate the corridor but the apartment kitchens and bathrooms as well. Buildings are responsible for 30% of global carbon emissions but 80–90% of those are said to be from the operational energy required for heating, cooling and illumination. The energy and resources used for the construction of housing in general and high-rise apartments in particular is not insignificant.

Urban housing is housing at relatively high densities and the most important problem is to ensure a certain minimum amount of space per person. Not unconnected to this is how to provide access to those dwellings, and how to ensure their spaces receive sufficient daylight and ventilation. On the left below is Kowloon Walled City existed as an extremely high settlement between 1950 and 1993 when demolition began. Its population density peaked at 1.25 million people per square kilometer in the 1980s. Each resident had approximately 4 sq.m of living space (about 40 sq.ft). The only spaces for daylight and air to penetrate the building were the narrow corridors between buildings that people used to access their space. At high densities, the problems of access, daylight and ventilation are all critical and, when taken to extremes, it is daylighting and ventilation that suffer most.

The apartment building on the right is a typical apartment building from some decades ago. The access stair is also the access corridor serving two apartments per floor with entrance doors at each landing. Opening onto the stair are what are either kitchen or bathroom windows (as there is a waste pipe). Here, the single architectural device of the stairwell solves access, daylighting and ventilation vertically for all floors. The windows of habitable rooms use the building setback (and the street beyond it) to provide daylighting and ventilation. Kowloon Walled City shows us what happens when there is no setback and the street is no wider than a narrow corridor.

THE PROBLEM

The problem this project sets itself is fourfold:

  1. To use a single architectural device to configure high-density urban housing,
  2. For this single architectural device to provide access, daylight and ventilation to all rooms and not just habitable rooms,
  3. For the configuration of the entire building to let inhabitants retain an awareness of their living with other people, but not to the extent that privacy suffers, and
  4. For the configuration of the entire building should ideally have the potential to be mass produced and erected quickly and at low cost.


When I’ve set a design problem and am working through it myself as a demonstration for the students, I don’t mind changing my mind, my tack, my idea and explain why. All I want to do is show that it’s okay to do that if the reasons are sound. However, that’s always after the problem has been set and “the process” has begun. When I created this first part of the sample submission post I was aware of thinking of the other two stages as well and what they would be. I thought I had to think ahead because it wasn’t going to look great for me as an instructor if I ultimately couldn’t solve the problem I set myself at the beginning. I began to wonder how genuine this thing called the design process really is if already I’m defining the problem in terms of what I know I can solve? This isn’t as odd as it sounds, because architects have a legal responsibility to not accept a job if they don’t have (or can source) the skills or resources to undertake it. We don’t know much about the design process but it’s clearly one of those curious processes that begin only when the end is known. Nobody would ever commit to a contract if this weren’t the way. The “work stages” are opportunities for the design process to be ended if the process doesn’t look like delivering an anticipated outcome in the expected time.

In the important exception known as competitions, all that matters is the sponsors seeing some link between what they expected (or thought they did) and the winning design that fulfills, exceeds or even resets those expectations. Nobody cares what happened in-between.

I’m beginning to think it’s misleading to teach the design process as some open-ended process of exploration. Firms that claim to be research-driven insist it is. These are the ones that have exhibitions with endless tables of study models to show us just how research-driven they are. All I see is are studios of underpaid interns and much time and labour being exquisitely folded into the invoice.

[Cite]

Comments

  • Actually this thing called the design process itself is a thing of the seventies, when various computer scientists, designers and thinkers sought to develop an intelligent computer algorithm to replicate the design process.. hence all the computer vocabulary.

    When many designers think of ‘problems’ in design, the model they seek is a scientific problem where the problems are ‘tame’ in nature, or in other terms very well defined with a set scope. Whereas the problems in design are often called ‘wicked’ which are hard to define and set the scope of.

    Design is mainly solution oriented, in that the exploration of the design problem is made by exploring a solution. Hence defining a problem is inherently solution biased as you explained. This I believe is a feature and not a bug of design thinking. Just what I gathered by reading up on design process and thinking thus far. Would love to know your thoughts.

    • says:

      Thank you Dheeraj for reminding me of Christopher Alexander and his book “Notes on the Synthesis of Form” which was around in the early 1970s and recommended I read at architecture school. It’s exactly what you mention. I tried to read it again last year but only managed to cover the first eleven pages. Notes on the Synthesis of Form Our terminology may have changed but we’re still doing the same thing and, worse, still teaching it. I like the distinction between “tame” and “wicked” problems and totally agree that they are hard to define and set the scope of. But we do so, In a way, the design process has begun before it can even begin. This suggests something is very wrong in how we think about it. I can see the attraction of pseudo-computational models but I disagree with the basic 1970s premise that the world is becoming more complex and so our buildings and their design must too. Thanks again.