A design is not just one final pot

The design process in architecture is not the same as seen in many of the other forms of creation.

Rather, it ought not to be like them

Many architects do tend to make architecture quite similarly to what happens, say, in fleshing out a sculpture or making a pot or creating some other work of art.

The architect proceeds from the initial, hazy, early stages of design and moves towards the final one — the architect is surely focused on the task at hand till a clear design is yielded at the end

I posit that it is imperative that while designing architecture, one ought to yield multiple alternatives for the same project. I am sure architects may not object to such an intention. After all, if we have many different alternatives to choose from, why would anyone object?

However, this is easier said than done.

I have heard that some major architects (e.g. Norman Foster’s office) do have separate teams that are given the same project to design. Each team comes up with their own solution — and in the end, they conduct a rigorous internal jury through which they select the one that the office would now go ahead with.

Large well organized and settled architects’ offices possibly can afford to do this. They can demand their additional fees too.

Ideally, this should be the way by which all of architecture ought to be designed. But how is that to be done, especially when time is short and you do not have enough staff, and all other resource issues of any typical architect’s office?

But before I recommend TAD (The Architect’s Desktop), the unique early stage BIM I am now offering free to the world — let me first convince you that it is imperative that architects produce multiple alternatives for the same project

So it is not like saying “Well, I wish I had time and resources to make multiple alternatives” I am emphatically saying “We all better produce multiple alternatives”

But why?

Architecture has three important characteristics that provide the reason

1. Architecture deals with the rarest of rare raw material: Space. It cannot be created.
2. Architecture exists in one singular universe. There simply is no alternative architectural experience to the one we experience with some piece of built architecture
3. Architecture, once it is built, cannot be easily critiqued

First point: Because space is a very rare raw material, it is important to respect any modulations/interference we architects do to it. That parcel of land is likely to remain modified for years to come due to our design intervention.

Sometimes, even for centuries.

So we need to be really sure what is coming up on that parcel of land, in that unique volume of space given to us to design, must be the best possible — at least the best of our capability. This point is easily agreed to: We have enough examples of the damage that bad architecture does to the environment and people

Second point: Because there is just that one universe out there and we all walk on a narrow path of time in the forward direction in that universe we can only experience whatever architecture that has been constructed out there.

We can always swipe down an app on our phone we don’t like — and then double tap to open an alternate one. In the same space and time of our experience.

But we can’t do that with architecture. We can’t stand with a remote control and elect to choose which architecture we want to now experience. What is out there, that is all there is for us and our users to use

The third point is a corollary to the second point.

Because, we can only experience one and only one piece of architecture all the critics lose their voice — or they better lose their voice — when the work is already built. To reverse engineer the design and think what else could have been done would be at best, only speculation. One cannot really know for sure that the climatic strategy that the critic wanted in place of the one that was built would really work. It is all conjecture — and only when that new strategy is used in an actual building would we know for sure

Hence, all criticism of a design must necessarily be directed before the design is constructed out there. Even more; the critic needs to have multiple choices — because there is really no perfect design for any parcel of land or for any project. The critic, if presented with alternatives, then can make a sane judgement on which of the alternatives can now go ahead

I wrote TAD as a designing tool (and not a drafting one) long time back for all the above requirements of being able to critique multiple approaches to the same design

In my audio podcast, I had indicated that one of the objectives of TAD is to give a systematic way of working out designs for architects everywhere. Hence this article.

Designing requires iterative thinking. In each cycle of these iterations, there are three stages: First stage you make value assumptions (Statements like “I want people using this project not to sweat in that hot-humid climate”) Then you need to flesh out a proposal for that cycle. The third stage is criticism — where you check if you indeed got the results you wanted in the first stage. The last act of criticism usually generates more insight about the design — and then you move onto the next cycle. A series of such iterations will yield the design.

(This iterative way of designing is well explained in John Zeisel’s book “Inqury by Design” — in fact, it maps quite well to the agile process in Software Development — there too, in the third stage, one does criticisms — popularly known as software testing)

TAD actually promotes such iterative design thinking. Moreover, as you keep iterating, TAD also allows multiple alternatives to emerge. In most of my projects, I have worked on many different alternatives— they may have started in similar manner, but as the iterations proceed, new branches of designing start emerging.

Then; I and others involved in the design in my office, pick the right alternative. Though I cannot afford to have separate teams to generate different alternatives for the same project, I do have the advantage of using TAD to produce alternatives.

It may not give the same advantage of having several different teams, but yes, it does help one come up with many different alternatives with the same team — provided this ethos of wanting different alternatives is felt

Curiously, this happens in software designing too where the software development team forks several different branches of the same software.