6. STRUCTURED PLANNING

6.1 The Paradigm: Form as a Diagram of Forces

The design process proposed here was pioneered by architect and urban planner Chris Alexander whose doctoral thesis, published as Notes on the Synthesis of Form, created somewhat of a revolution in the design field in the late 1960s. Now known as "Structured Planning", this and later work such as Alexander's A Pattern Language continues to attract adherents but so far primarily in the design of things physical: buildings, environments, transportation systems, medical technology, electronic devices, etc.

The paradigm behind this design process is based on the notion of "form as a diagram of forces", an expression of "form follows function". This notion is easily observed in biological forms. A cell membrane containing fluid surrounded by equal atmospheric pressure resolves into a sphere; closely packed, these cells resolve into hexagonal cross-sections. The structure of a large quadruped (like a dinosaur) tends to resolve into a double cantilevered structure, the head and tail balancing the stresses on the central frame. The boundary conditions of these forms economically resolve their internal forces with those extant in the environment, and the resulting equilibrium is a model of pure functionality. For all its apparent complexity we know this intuitively and admire nature for its simple beauty.

Taking the lesson from the natural world, the design paradigm emphasizes creating forms that have, in the biological sense, "fitness" with its context or environment, hence, a simple, elegant and functional beauty. In physical design and engineering there are many good examples with analogies in nature. Suspension bridges have the same overall structural form as big dinosaurs. Geodesic structures look like gigantic diatoms and radiolaria because they resolve the same overall distribution of forces.

Some of the forces that good architecture and product design must resolve are psychological and social rather than physical. For example, given the context of a small house, making it long and thin as opposed to square and squat resolves the needs for privacy against the constraints of a limited budget and space. In software design many of the forces to be resolved are the constraining limitations of current technology and economics against the psychological requirements of the user: those of purposive behavior, cognition, perception, group interaction, etc.

The design process of Structured Planning described below is based on this paradigm. It is a method for dealing with the myriad design requirements in large complex open systems in order to achieve the kind of resolution, fitness, and equilibrium that biological forms have, resulting in software solutions that are elegant and beautiful simply because they work so well.

6.2 Project Statement
(Problem Definition, Design Scope)

The Structured Planning process usually begins with some sort of overall project statement, essentially a goal statement or problem definition. The project statement should scope the problem space in terms that avoid preconceived solutions, but in a way that all of the design team members (and the customer) can agree and buy into it.

The overall project statement can be further explicated in more or less formal terms. Some designers rigorously document the issues to be addressed by the design project, including constraints, objectives and directives, background and arguments, etc. In this way, the goals of the project are explicit. Without such an exercise, the goals are often skewed by dominant personalities rather than all those with insight into the design problem. Furthermore, they are often stated so vaguely (if at all) that those working on the project have radically different ideas about where they are going.

6.3 Design Research and Analysis

6.3.1 Functional Analysis

After settling on a good project statement where the goals are clear, the design team continues with a functional analysis of the problem space. As in the project statement, it is important to avoid thinking in terms of preconceived solutions or existing structures. Thinking in terms of functions allows the analysis to be specific and informational while sufficiently abstract to lend itself to suspended judgment, lateral thinking and creative solutions. To illustrate: facilitating the function of "trash removal" rather than providing a "garbage can" opens up a broader range of solutions, for example, recycling bins or preventive solutions that reduce trash via reusable packaging.

If the project is to invent an entirely new system the design team may begin with a top-down analysis of required functions. If the project is to improve an existing system, the analysis may begin with a structural model (a hierarchical breakdown of components), but even then, the components should be defined in terms of their functions. After all, the better solution may entail completely different components. In either case, the goal is to produce a thorough functional model that includes all users of the system throughout its lifecycle in all its modes of operation. This includes not only human factors but also factors of integration, release engineering and manufacturing, maintenance and support, adaptability and upgrades, etc., and in the commercial world, benchmarks against the competition.

6.3.2 Problem Elements (Design Factors)

For each of the functions the system must perform there are a number of real and potential problems, i.e., forces that must be resolved by the system's form. The forces may be directly observed, derived from literature search, inferred from constraints presented by the system's environment or context, or generalized from observations about people using similar systems. As elements of the problem space, they constitute design insights that have been variously called "misfit variables", "requirements", "problem elements", or "design factors".

Regardless of what they may be called (this document will use the term "Problem Elements"), they are individually recorded on 1 to 2-page documents along with ideas that might resolve the forces. The documents are written in a language that expresses the insight in terms of force-tendency relationships, requirements of fitness within the functional context, or at least a circumstance-specific observation, and in a common format so that they can be related to one another. In this way the data is reduced to real information; it has heuristic value for generating design solutions because it describes the underlying forces that must be resolved in operational terms.

There are more and less rigorous methods to discover Problem Elements. Charles Owen^[1] proposes Action Analysis documents that describe the system's functions at an elemental level. These are systematically used to generate the Design Factors (a.k.a. Problem Elements). A less systematic approach may be employed, especially for smaller, less complex design problems, but in any case the team should be careful to cover all the users of the system in all its modes of behavior, and in all its various operational environments. Moreover, as the goal is problem identification and analysis, Problem Elements are often based on (and may cite) information generated from the use of "left brain" or "glass box" methods and tools.

See our Problem Element document template, annotated with descriptions of the content for each section.

[1] Design For Integrity , Charles Owen, Illinois Institute of Technology, Institute of Design