[ 8] Alexander, C. Notes on the Synthesis of Form. Cambridge, MA: Harvard University Press, 1971.

cation of the more familiar A Pattern Language. The methodology in the manual specifies a structure for setting up design problems in order to find gen-eralities, particularities, and eventual solutions. The authors considered it a “minimal and natural” format: the what, where, and how of a situation; in other words, the problem, the context, and the resulting pattern [ 6]. Shifting the focus to the definition of the design problem and not just its resulting pattern helps to ensure the pattern properly addresses the situation, particularly in complex environments.

Alexander long maintained an interest in defining a design methodology in the face of complexity. Notes on the Synthesis of Form, originally published in 1964, more than 20 years before A Pattern Language, outlines the difficulty of designing for a series of intermeshing, interacting systems, even when the final designed object itself might not look complicated. “In spite of their superficial simplicity,” Alexander wrote, “even these problems have a background of needs and activities which is becoming too complex to grasp intuitively;” needs and activities that sit within a growing ecosystem of other pressures, whether social, cultural, or informational [ 8]. In this setting, Alexander found no place for the secret, intuitive processes traditionally claimed by many designers, ones which did not take the intricacies of their contexts into consideration. Instead, he advocated a logical, objective approach to design, in which form fit context by addressing a set of design requirements. With

these requirements, Alexander expanded the architectural notion of program (it specifically means the set of functions fulfilled by a room, space, or building). It is a program, he wrote, “because it provides directions or instructions to the designer [ 8].” If this sounds like engineering language, it is no surprise. Alexander developed design-requirement data sets in the early 1960s that were complex enough to necessitate an IBM 704 mainframe computer for analysis. With his colleagues at the Center for Environmental Structure, Alexander moved away from such a byzantine analysis of requirements, instead seeking a method for creating straightforward descriptions of the program—that is, the design problem—in the Pattern Manual.

The manual defines a grammatical structure that maps to a designer’s mental model. A designer follows three steps when developing a pattern, “or, for that matter, [when he] entertains any idea about the physical environment…. He considers a problem, invents a pattern to solve the problem, and makes a mental note of the range of contexts where the pattern will solve the problem [ 6].” Contexts and problems are paired with each other—wherever a particular context appears, so too does its problem. The context modifies the pattern in the way that an adverb modifies a verb: It says how the pattern works and in which circumstances it is valid. The problem statement provides the reasoning behind the pattern and context. It can be much lengthier, offering an explanation of the situation, a “common-sense description of

the problem, as it exists today [ 6].” The pattern, then, is a set of parts that relate to each other in space. Patterns can address anything from the appropriate layout for a kitchen, to freeway ramps, to designs for users of a certain income or educational level, to furniture design, to structures that hold up houses [ 6]. Where they can address a huge variety of problems, they themselves seek to be reductive and essential, offering only what is necessary. Where patterns might not provide the only solution to the problem, without it or an equivalent, “the problem will go unsolved [ 6].”

Although titled the Pattern Manual, its heart is the design problem statement—the most important element “from a human standpoint [ 6].” Problems subsume the considerations that system designers address, called “functional demands… [that] at one time or another [have] been called requirements, needs, performance standards, facts, tendencies, objectives, constraints, activities, technical data, and so forth.” Yet the functional demands do not stop with what a system should do: They address a wide variety of issues surrounding the ecology of a system. “They may concern human behavior, economics, the state of technology, the political climate, whatever. No limits can be placed on the kinds of elements necessary to describe a problem properly [ 6].”

If that sounds vast, it is. Patterns address an astonishingly wide variety of elements that are organized in space in some manner. The Pattern Manual offers an expansive list that includes “all kitchens; dormitory