Post your comments on this discussion

Design Moves, and a discussion of Schon’s "Reflection in Action"

A mathematics problem

Let’s start with a mathematics problem from linear algebra. Two points (x1,y1) and (x2,y2) describe a line in the plane. You wish to calculate the slope of this line, and the point at which it intersects the vertical (y) axis. Call the slope m, and the y-intercept b. How to calculate these numbers, given numbers for x1, y1, x2, and y2?

The problem is to come up with a formula for y and b, in terms of x1,y1, x2, and y2. Drawing on our reserves of knowledge from middle-school days, we remember the formula for slope:

slope m = delta x / delta y,

m = (y2-y1)/(x2-x1).

That solves part of the problem - given the coordinates for the two points we can compute the slope; but how about the y intercept? Again we reach into the ancient past and retrieve a general formula for a line:

y = mx + b

And, because we’re looking for b, we subtract mx from both sides of the equation (again, something we remember is a legal operation) and obtain:

y-mx = b


b= y-mx

What now? We have two equations, and both mention the slope m. We remember that we can substitute, so we try that, and arrive at:

b= y - (y2-y1)/(x2-x1) x

We’re stuck here until we recall that the equation is supposed to be good for all values of x and y on the line. So, we can substitute any values for x and y on the line in place of x and y in the equation, and so we decide to substitute the values for the first point, (x1,x2). We obtain:

B = y1 - ((y2-y1)/(x2-x1)) x1

And we are done: we have an equation for b in terms of x1, y1, x2, and y2.

Schon’s "the design studio"

Schon reviews a session between a studio teacher and a design student, in which the student claims to be stuck, and the teacher responds by working the problem in front of the student. Schon argues it is a demonstration of working design expertise, and it reveals the way a designer sets up or ‘frames’ a problem in order to solve it,but remains willing to break the framework or abandon it if that turns out to be necessary. He also argues that architectural designing is a process of ‘reflection in action’, or a ‘reflective conversation with the materials of design’.

At least some parts of this point of view ring true. Designers proceed in a series of moves, recorded as marks on the paper, each of which sets a context for further action. Some of the moves have profound of global implications for the rest of the designing; others have only local implications. For example, choosing a site orientation or selecting a grid for a building is likely to govern a great many of the decisions that are to follow, but designing the entrance condition is likely to be mostly a local decision.

In designing, we propose a move by drawing it, and then we examine what we have drawn, thinking of the consequences that are likely to flow from it. We often try several alternatives, and select the one that we deem most promising. In this way, designing is a little like a game of chess, in which we propose several alternative moves, consider their consequences, select the one we think best, and then proceed.

Back to our mathematics problem. When we learned to do algebra, we learned certain facts, like the formula for the slope of a line, and the slope-intercept form of the equation for a line. We remember these formulas, and when we’re called on to solve a problem in linear algebra, they come to mind as relevant to the problem at hand. When we’re presented with the problem, the problem reminds us of this knowledge. We also remember that we are allowed to perform certain operations on the equations. We remember that we can substitute the expression for slope from one equation into another. We remember that we are allowed to subtract a value from both sides of an equation. In each of these instances, we may or may not remember the argument or proof that justifies the fact (equation) or operation (substitution), but this isn’t necessary in order to solve the problem.

Compare now, doing design with working the math problem. Are there facts or propositions that spring to mind when called to produce a design? Are there operations, or transformations, known to be legitimate, that spring to mind when examining a drawing? I think there are. We learn these ‘facts’ or configurations of form - ways to arrange structural support (posts and beams, masonry walls) and to make space (patterns of containment and continuity; how to make a privacy, and how to define shared or community space); and how to manipulate the elements of material - transparency, surface. We learn also how to transform or permute a drawing, how to rotate, repeat, reflect, the elements of a floorplan, and to substitute equivalent forms, to articulate detail to evaluate a design proposal made abstractly, and to abstract detail when working ‘bottom up’ to apply a specific idea in a larger context. And, just as we can check a mathematics equation by plugging in specific numbers, we can check a design by putting in the furniture and imagining real people using the space.

From the Schon piece, then, several themes emerge. First, there is the notion that designing proceeds as a sequence of moves, recorded externally and then examined, and that the process of examination (reflection) suggests or triggers certain responses. These responses, learned previously and applied to the situation at hand, are then recorded and examined again. Every design move has consequences, which the skilled designer anticipates and can strive for. Second, there is the notion that strategy plays an important role. Some moves are more consequential than others, global in their scope, and set the stage for a stream of more local and particular decisions. The experienced designer makes some larger moves, as propositions that can be withdrawn or, on occasion violated, and then proceeds to play out the consequences as a series of local moves within the scope of the global proposition.

Design Computing

What then is the connection of all this with design computing?

In the first place, we argued that in order to build tools for designers, it may be valuable to study designers in action. Schon’s study of design teaching (or coaching) is an example. He looks to the design studio for the articulation of expertise in arhitectural design, and finds it in the exposition of the teacher Quist in talking with the student Petra. And from this exposition he comes to a sort of theory of architectural design expertise - that he calls ‘reflection in action.’

More specifically, then, if this is all so, what are the facts and the operations of architectural design? The program called Mathematica has its roots in an artificial intelligence program called MacSyma, developed at MIT in the 1970s. Macysma was a program that helped mathematicians solve complicated symbolic problems, like solving differential equations. Macsyma was programmed with the rules for symbolically transforming equations, algebraically, adn large tables of differential equations. This was all stuff that any good mathematician could do by hand - nothing artistic about it, but it required a lot of tedious manipulation of the equations and searching books of tables for the appropriate substitutions. Macysma made it easier for a mathematician to work differential equations, by automating the symbolic transformations of equations. We usually think of a computer as a sophisticated numeric calculator; Macsyma was a sophisticated symbolic calculator.

So the question is, if we would build a Macyma for architectural design, what would be the transformations and equations? Instead of simply managing designs at the level of simple geometry (points, lines, and planes) - think of this as the equivalent of a calculator, what if we could manipulate designs at a symbolic level? Is it possible to provide a set of ‘routine’ form facts and transformations? Could these be the basis of a new kind of CAD program, or design machine?