7. DESIGN PATTERN LANGUAGES

Design teams that routinely use Structured Planning soon realize that some of the same individual Problem Elements (or even entire solution sets) come up in similar design projects. To the extent that the functions and contexts are similar in different projects, the conflicting forces causing real or potential problems tend to be the same, and generic solutions can be specified to resolve them. These recurring context-specific ensembles of generic problems and solutions comprise design "patterns" that can be applied to different design projects.

A design pattern describes the parts (functions or structures) to which the pattern applies, the context in which the problem occurs, and the forces involved in creating the problem, but most importantly it specifies a generic rule of thumb, or heuristic, for the form that resolves the problem. Patterns can be given titles that fit naturally into the discourse of a design team (per Noam Chomsky). After a body of such patterns is built up, they constitute a "pattern language".

A software company could build up a pattern language over time from design projects using Structured Planning. Such a pattern language for software systems could become a corporate memory for design issues, providing direction for an evolving coherent family of products over time. A software Product Design Framework would ideally enable and support a growing design language of this sort.