Inventing the Future with Structured Planning
Systems Design Methodology for Software Products
Version 2.1, June 6, 1995
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.
For all its apparent complexity we admire nature for its simple
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
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
Software solutions that are elegant and beautiful simply because they
work so well.
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.
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
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.
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.
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.
There are more and less rigorous methods to discover Problem Elements.
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.