Architecture Myths #29: The Problem

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.

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.

---

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]

NOTSOF [p.1-11]