The Theory of Design

The missing link between design beliefs and technology decisions - what practice leaders need to define first.

In exploring how technology impacts architecture, I’ve looked at digital transformation, design technologies, digital and business strategies, BIM (and BIM2.0 now) and technological impacts from other industries.

One of my observations was that the practices that were more successful in their technology adoption were a lot more intentional in their pursuit of digital change. They’ve developed their digital practice through one lens that gave purpose - the Theory of Design (ToD).

H2: The Theory Explained

In essence, the theory is very much an inherent concept of the practice and how they operate. I like to define it as the fundamental belief in how you do design. The intrinsic approach to design and delivery of architecture.

When I speak with practices, I can see how they think about architecture, but not always their beliefs - the core element/s. Now, this is not a design philosophy like Modernism, or Brutalism, or any design style we know and have studied; it goes deeper. The design style is how we express our theory at the end of the day.

For clarity, I use the following distinctions:

• Theory of Design - How we believe architecture comes into being.

• Philosophy - What architecture should be.

• Style - What it looks like when completed, executed.

The Theory Unmapped

When I started looking into the concept of the theory, I started wondering how to make sense of it. Instead of giving you a roadmap, I would rather give you clarity from recognised patterns that come from when a Theory of Design is missing.

When a Theory of Design is missing or unclear, I see these patterns repeating themselves.

(Un)Spoken Rule

While consulting firms on their technologies and implementation plans over the years, I find myself wondering why some were successful and others were not. Why do some firms adopt and fully adapt to new technology, while others just keep using the old one?

I came to understand the (un)spoken rule within the practice.

“Technology is a means to an end, and it doesn’t define us.”

“The intentional adoption aligned with how we do design is part of the core.”

This rule, correct or not, became the first lens I saw. This is reflective, in a simplified illustration, of Zaha Hadid Architects (ZHA), who believe in the creation and challenging of forms as their spoken rule.

(un)Filtered

I saw the opposite when I started asking people about their theories of design; their ideas are unfiltered.

In one conversation, the principal was clear on his belief of what architecture is, but for the practice, it wasn’t aligned; the practice’s theory was jumping between 2 or 3 definitions. This mixed belief makes it more difficult to design a system into the practice.

Right to the tech.

Most practices talk a big game, but when you start looking at where they ask for help, it goes directly to the technologies. They become responsive to the technologies and fall for the vendor-led conversation, where the selling of ‘doing’ is done before the definition of the theory is defined.

”Theory without practice is empty; practice without theory is blind.” ~ Immanuel Kant

Most of the failures I’ve seen sit here, at this level, where we adopt the technologies because we need to change. We never stop to ask how the technologies support our theories, how our culture will respond to this and ultimately, ‘does this make sense for us?’

How does this theory talk to technology or the practice?

This relationship becomes clearer when going through the four system levels: Practice, Capabilities, Processes, and Task Systems.

Let’s continue to use Zaha Hadid Architects as our case study.

Practice Systems

The first step is to define the theory of define at the highest level of the practice - the founders or principals.

ZHA started this practice with a core belief of how they see architecture within the world, as mentioned, ZHA has this belief in the true form creation for architecture - the idea that form, no matter how wild it feels to us, is the foundation of their design - as such, the theory creates this fundamental belief that new forms is the ultimate way.

For them, they imagine forms for buildings or spaces in such a way that they might not have the right capability systems in place.

Capabilities Systems

The capabilities system translates this belief into people and technologies.

If we believe in form creation and that we should challenge every form to elevate it, then we need people who can think of architecture in forms, and we need technologies to drive this creation.

They might start exploring software that, more commonly, would allow them to experiment with forms, software like Autodesk Maya, McNeel Rhino + Grasshopper, etc. They would explore any technology that would enable them to go from theory to execution.

And to add to this idea, Revit might not even feature on their list of recommended software, although they still use it for the documentation of their buildings through the design delivery processes.

Process and Task Systems

From these capabilities, we can design the process and task systems - the way the practice actually operates.

Process systems define how capabilities are applied: hiring, form development, and the transition from exploration to delivery.

Task systems formalise the how: SOPs, guides, and repeatable actions.

The Theory of Design for the Digital Practice

To give your digital practice, the side of the practice that focuses on the technology for design exploration and delivery, a north star; the Theory of Design is just that, the things that give them a direction to find the right technologies and capabilities.

This path forms a guiding principle without hard rules or defined requirements and allows the culture find the technologies that fit their processes.

The biggest caution I will give is that ultimately, your Theory of Design does come with trade-offs, so find and understand them.

If your practice had to say no to a technology today, what belief would you use to justify it?