Design Language


A key use-case for Pattern Languages is in the contect of work to build new systems, or, more often, to improve existing ones. These are Design Languages...


Design in complex domains is always subject to unintended consequences with negative impact

Interventions in complex systems are subject to the Iron Law of Unintended Consequences. Since such systems exhibit strong path dependency, sensitivity to intial conditions (aka butterfly effects), recursive feedback loops which themselves interact and so on, the outcome of any given intervention is sure to produce some unforeseen results.

These may be benign, insignificant or even welcome. Equally, they may have effects which run counter to the intent, or produce larger negative effects in related conditions. The point is that they will occur.

Design Pattern Languages seek to map a system into relatively understandable domains - Patterns which are carefully identified and documented in such a way that each is recognisable - A Pattern is a whole - so that building an 'in memory' model is within the working capacity of human cognition.

In this way, each pattern can engage the full creative and analytical capacity of the human brain - both conscious and pre-conscious.

Each language is structured according to some Hierarchy of Scope, so that it is practical to select a mode of intervention appropriate to the resources and ambition of the design work at hand.

Relevant patterns are selected and form a framework for the development and testing of the design vision. Work with this model should give increased capacity to identify and understand the reasons for emergence of at least some unintended consequences.


Frame Design Pattern Languages as multi-faceted statements around positive intent in a domain, is structured on the basis of careful analysis of recurring patterns and the conditions in which desired qualities can emerge.


We will refer here to some patterns derived from Cynefin about 'best practice', 'good practice' and 'emergent practice'.