I get excited when I come across a book that attempts to apply rigour to an existing field, especially in an area I work. I recently indulged in Notes on the Synthesis of Form by Christopher Alexander, and that’s what it was for me, an indulgence. Alexander applies a more scientific approach to design to conceive of a new way of solving design problems. Written in 1964, he focused on architectural design as his medium, though I find the ideas applicable to modern digital design practices 50 years later.
If I was to summarize his approach, it’s a sequence of 1) decomposition, 2) design, and then 3) recomposition. Much like the old “take it apart and put it back together again” method, in a more formal way. At its core, Alexander’s description of a successful design is one that fulfills all criteria; it has no “misfits”. He gives the example of a well-designed house. While it’s hard to know when a house is well-designed, we can identify when we encounter a poorly designed house with ease. Perhaps there aren’t enough windows, or the doors are too narrow for what we like. These small issues are examples where there are misfits in the design.
The goal then with the design process is to identify everything that will result in a misfit, requirements in modern product parlance, and design against those. These requirements are often tightly connecting, adding incredible complexity to a problem that seems simple at first blush.
Before going through the process itself, it’s interesting to consider how this applies to product work. In many ways, you are responsible for designing the product. By this, I mean what the product is, what the business will be, and how it will succeed. Typical design activities (interactions, experience, visuals) are still relevant, but the scope of those problems is far more narrow than what it could be. Applying Alexander’s methodology enables you to address far more complexity in both strategy and product building than it may appear. As we will explore in a further essay, addressing interconnected requirements is an art and what leads to something new.
Decomposition
Decomposition is a powerful skill. The ability to take a problem or a concept and identify its constituent parts allows you to unlock a new level of insight. It’s a skill worth refining for problem-solving, for understanding, learning, and invention.
Decomposition is a process of understanding where fits or misfits could occur in a product and its context, also known as a form-context ensemble. As I started to explore in both What is a product? and Winning with Mediocrity, a product’s context is so critical when conceiving a product. Without it, you will be unable to design value for customers. Decomposition allows you to expose the inner workings of a problem or a system.
In Alexander’s examples, his design problems often have hundreds of interconnected requirements. What makes this approach so interesting is you need to map the relationship between each requirement to understand how solutions may impact the other requirements. I believe products today, even relatively simple ones, will have even more requirements as our contexts have evolved to have increasing amounts of complexity.
Design
This phase is where you get to solve the problems. Through the process of requirements gathering and decomposition, we have broken out what we are designing into atomic units, the smallest possible form. Now we go through the process of solving each individually; things are getting interesting.
Since a design can either satisfy the requirement or not, you can evaluate a design mathematically with a set of booleans. Each requirement is either met (true) or not (false). Your objective is to flip the boolean to be “true” for the identified criteria. If you are evaluating requirements on a scale or a bit more subjectively, you need to break it down further into something true or false. It’s now a matter of designing each piece in a way that maintains true for every requirement. It reminds me of the Lights puzzle, where each switch you turn on, it inverts those surrounding. You have to manage the connected pieces to find the working solution.
The process can be challenging when working in a more complex context. It becomes an iterative process with Recomposition as you attempt a solution, try to integrate into a broader solution, and rework it if things break. This should feel like the design process we know and love.
Recomposition
Recomposition, also known as integration, is the final step. It’s the process of integrating each of the individual pieces into a final product. This typically follows the same series of levels that you created in the Decomposition phase. As you solve each branch of the problem, you are trying to see if you can assemble it into something intermediate, before the final product. As you test the design at each level, you may discover new fits or that the design doesn’t work. This is frustrating, but natural.
Alexander’s approach reminds me of a couple of interesting connections I have come across. I wrote about the Pyramid Principle a couple of weeks ago. While I didn’t cover it in the piece, a core part of the approach is to abstract disparate data and categorize it to make sense of the information. This process feels like the following step of Alexander’s approach: unpacking a problem into a multitude of miniature conditions. I found the parallel between the strategic thinking process and this quite fascinating. The other piece I recall is the briefing The Strategic Game of ? and ? by John Boyd. In the presentation, he goes through the process of decomposing a series of products or observations into atomic pieces that he reassembles into a new creation. It reminded me of the same process and a similar skill set.
Simplifying Complexity
“To me, coming from applied mathematics, a theorem was a statement about an everlasting mathematical truth—not the dressing up of a trivial observation in a lot of formalism.” – Brian Arthur in Complexity: The Emerging Science at the Edge of Order and Chaos
If I were to have any criticism of the book, it would be the overly formal nature and expectation Alexander has with his method. I don’t see a world where we apply mathematics and set theory to a design problem in practice, though I understand the conceptual value to see a problem in this way. What a designer needs to understand is that requirements should capture not just functional requirements, but experiential ones as well. These requirements are binary, though interconnected. It’s not as easy as treating it as a checklist; each design decision you make will disrupt the effectiveness of previous choices. Your goal is to satisfy them all at once.
I think I might have enjoyed the book so much because it mapped to how I already think about problems. Did I learn anything new from it? Perhaps. I have an expanded vocabulary for thinking and talking about form-context problems. It also reminded me of how I should be approaching these problems. Additionally, this thinking is feeding into a future piece about mapping connections within a business and its context to drive growth decisions.