In its details of construction it still falls far behind
It has great beauty of layout. But in its details of construction it still falls far behind. Indeed, in its construction it is completely spoiled. For reasons outside our control, it was necessary that this particular building, once laid out, was then “detailed” by ordinary processes. It was taken to the drawing board, by people who had not laid it out, far from the site, and given mechanical “drawn” details, quite inappropriate to its design … until it became, in the end, no different from a thousand ordinary buildings of our time. In short, it was almost destroyed, because it was not built in the right way. At first I hesitated, I was not sure whether to write this, or whether to include the picture, because it is so sad and so depressing. But then I realized how essential it is to include it: because many people may be willing to lay out a building in the way I have described, and will then try to get it built from drawings (Alexander 451).
I love how Alexander spends a whole chapter talking about this beautiful design they created, only to have it be utterly butchered when it came to the actual implementation. “Looks great in Figma”. You see this a lot in software where the end result looks like nothing the designer envisioned and this usually happens when the engineers are the people who “had not laid it out” and are too “far from the site”. Or rather, “throwing designs over the wall”.
Placing Stakes Together/Walk It Out
Dr. Ryan told us, after his clinic was built, that this one week he spent with us, shaping the building, was the most important week he had spent in five years the week in which he had felt most alive… The simple process by which people generate a living building simply by walking it out, waving their arms, thinking together, placing stakes in the ground, will always touch them deeply (Alexander 453).
There’s something immensely powerful in designing things together with the people who will actually be using the thing and the people who will actually be building the thing. Some of the most memorable highlights of my career have been the times where I was working directly with stakeholders and users of the actual thing I was building and riffing off a hundred “wouldnt-it-be-cools”.
I once built some software for salespeople to streamline the quoting process for a Gazebo-building company. I wasted a week trying to “gather requirements” before I finally drove over, sat down and asked someone to “sell me a Gazebo”. And we quite literally “walked it out” through the showroom floor and I got to see for myself what the actual difference between wood and composite flooring was.
The farther you get from the user, the more sterile your “requirements” become.
Constrained by contracts to make the building exactly like the drawing
…if the builder builds according to a detailed drawing, and is constrained by his contract to make the building exactly like the drawing, he then makes the detail identical, to follow the drawing-and in the actual building this becomes dead and artificial (Alexander 462).
This reads exactly like an argument against trying to be “pixel perfect” and taking a Figma design too literally. Instead, Alexander argues that builders (engineers) need to build the design using the same pattern language that created it. A consequence of this is that you will always get a slightly different result each time you apply the language, but that’s exactly the point. If the patterns and the language are good, the result will always be good. They may not match what’s in Figma, but they will match the intent of the design.
This goes against just about every “best practice” today. We simply have no mental model for patterns like this. The best “patterns” are at best just big components.