Data Driven Design: what is the best design?

In the previous article I argued that most architectural decisions are rules and numbers. That leaves the hard question, the one an algorithm forces you to answer before it runs: what is the best design?

Because an optimizer doesn't choose for you. It needs you to state what “better” means in this project, in a sentence precise enough to be measured. That's where the work gets uncomfortable, and also where it gets interesting. That's what I call Data Driven Design: not using data as decoration, but declaring the criterion before drawing.

The algorithm doesn't replace judgment, it forces it into the open

In a land subdivision the algorithm doesn't start from nothing. Someone has to draw the guide lines, decide where the access comes in, define what's being optimized. The computer tries thousands of scenarios, but I write the rules of the game.

And that's where the question shows up. Do we keep the option that yields the most lots? The one with the most even areas? The one with the best frontages? Those are different answers and all defensible. That decision used to stay implicit in the hand of whoever was drawing. Now it has to be written down, and that changes the conversation with the client.

Beautiful, ugly, and somebody else's millions

There's a part of aesthetic judgment that can't be reduced to numbers, and I have no interest in pretending otherwise. But there's another part —rhythm, proportion, orientation, how much façade you see while walking— that is describable. And that part is exactly the one you can defend in front of someone who doesn't share your taste.

I saw this up close during the MDI at ESE Business School, sitting on the side that evaluates the investment. If you're going to ask a person or a board to put millions into a building because you find it beautiful, they won't let you. And they're right: “beautiful” isn't an argument anyone can audit.

The algorithm doesn't tell you what is beautiful. It forces you to say what you're optimizing, and that can be argued at a table.

A building that orients itself by who's looking

The example that explains this best is an algorithm I built for a commercial building. I placed two viewpoints on each of the streets that mattered for the project, at pedestrian height. The rule was a single line: cast rays from that point toward the façade; if the ray lands, count one; if it doesn't, count zero.

The winning position and rotation were the ones with the most hits. Nothing else. And the result was a massing nobody would have drawn by eye: the façade arranged itself so that someone walking those streets would see as much of it as possible. For a commercial building that's not a formal whim, it's the business.

The point isn't the geometric trick. It's that “it looks good from the street” stopped being an opinion and became a number the client could review.

And another that rotates for light and views

The same logic applied to housing: here each apartment changes its orientation based on the sunlight it receives and the view it has. The result is that stepped pattern, which looks like a wall of giant bricks.

Nobody drew that pattern. It's what remains when you let each unit settle into its own conditions. I like it as an image because it makes the whole point obvious: the form is the visible consequence of a rule, not a gesture applied on top.

When the algorithm fails and the mistake helps anyway

It doesn't always work. On the Parque Bío Bío project one of the results was a disaster: the algorithm optimized exactly what I asked for and returned something unbuildable. But the form it produced had something. I looked at it for a while and ended up starting the design from there.

This is a part of the work that rarely gets discussed. A badly framed optimizer doesn't give you garbage: it gives you a literal answer to a badly asked question, and sometimes that answer shows you a path you wouldn't have looked for. Beginnings are rarely what you expect, and several times they took me somewhere I hadn't imagined.

Where else decisions can rest on data

These are the fronts I most want to push on, and several already have measured backing:

What's interesting isn't each one separately, but that they contradict each other. There's research measuring it: optimizing only for energy use ends up shrinking the window and lowering useful daylight. There's no solution that wins at everything. There's a front of solutions where each gives something up, and choosing among them is still the architect's job.

Design doesn't have to fight profitability

This is the part I care about most. We tend to treat commercial requirements as a constraint that takes away freedom: the client asks for more sellable square meters and the architect defends the project. It's an exhausting conversation and design almost always loses it.

But if commercial KPIs come in as parameters from the start, they stop being the enemy and become an input. The commercial building that rotated to be more visible from the street didn't trade design for business: it found a form nobody had drawn, precisely because the business was in the equation.

That crossing between what profitability demands and what design proposes can bear unexpected fruit that satisfies both sides. It doesn't always happen. But it happens far more often when both conditions are written down on day one, instead of negotiated at the end.

If you want the machinery behind all this —what Grasshopper is, how an evolutionary solver works and why the term is older than AI— it's in parametric architecture.