Design Pattern

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

Open this document, and create a copy or download it to edit: http://goo.gl/M45qa

Use the headings in this template for your design pattern. Replace the guidance notes with your content.

This template is intentionally expansive. Use the parts that make sense to you, and delete the rest.

Name

Design patterns are intended to be used as part of a pattern language, as an infrastructure for design-level conversation. As such, the name of a pattern should be amenable for use as a noun in such a conversation. It should be short, memorable and indicative of the big idea of the pattern.

Summary

Write this last.

The Design patterns paradigm (Alexander et al, 1977) was developed as a form of design language within architecture. This was done with the explicit aim of externalizing knowledge to allow the accumulation and generalization of solutions and to allow all members of a community or design group to participate in discussions relating to design. These patterns were organized into coherent systems called pattern languages where patterns are related to each other. The original definition of a design pattern positions it as a high-level specification of a method of design which specifies the context of discussion, the particulars of the problem, and how these can be addressed by the designated design instruments. A pattern has three facets: descriptive, normative, and communicative. It is an analytic form, used to describe design situations and solutions; a meta-design tool, used to highlight key issues and dictate a method of resolving them; and a communicative tool enabling different communities to discuss design issues and solutions. The core of a design pattern can be seen as a local functional statement: “for problem P, under circumstances C, solution S has been known to work”. Design patterns were described as abstractions of expert knowledge; they generalise from successful practice without detaching from its context. As such, they offer a two-way bridge between practice and theory: opening practical wisdom to theoretical scrutiny and allowing theory to be projected into practice.

Illustration

A graphic or photo intended to provide the reader with a vivid mental image for the pattern.

Problem

The problem description provides a clear and succinct presentation of the motivation for the pattern, its raison d'être.

The educational research literature tends to shy away from the term “problem”, as it may suggest a negative attitude. This thesis takes the position of the design literature, and specifically the computer science tradition, were problems are seen as opportunities for action.

From a design perspective, where there is no problem, nothing needs to be changed, no act of design is required and consequently there are no questions for research.

Synopsis

A single sentence highlighting the essence of the problem.

Forces

The objectives and constraints constituting the problem. Often the complexity of noteworthy problems emerges from a tension between forces: objectives which seem to contradict, or are incompatible with the constraints.

Context

A fundamental premise of design is that problems and solutions are rarely universal. The scope of any statement needs to be qualified if it is to be meaningful.

Origins

The origins of a pattern define its context in the most reliable manner: the characterisation of the common features of the situation descriptions of the design narratives from which it was derived.

Material

What are the spatial characteristics of the settings? What tools and resources are available to protagonists?

Social

Who are the protagonists, what are the relationships between them, and what are the social and institutional configurations in which they operate?

Intentional

What are the protagonists beliefs, desires and intentions, which shape the problem space?

Force Map

A Force Map is a graphical representation of the context of a design challenge. It includes iconic representations of the key elements in this context (social, material and intentional factors), and lines noting the relationships between them. These relationships are marked "+" when supportive, and "-" when indicating a tension. The design challenge can often be defined in terms of resolving some of these tensions.

Expansion

Based on the analysis of the pattern, it may be justifiable to claim a broader scope of applicability than can be directly deduced from the originating narratives. Such a claim is speculative until verified experimentally or by independent application, and should be noted with caution.

Boundaries

Specifying the boundaries of a pattern – where it does not apply – is arguably as important as where it does. These boundaries need to be clearly marked where there is a risk that a pattern would be applied erroneously.

Solution

The solution is the centrepiece of the pattern. In scientific terms, it is the claim that under certain conditions the described actions will have a particular effect which addresses the problem.

The solution would ideally be articulated at a level of detail which allows immediate implementation, and yet is applicable beyond the specific experiences from which it is described. However, in a hierarchy of patterns, several levels of abstraction will be represented and the respective solutions will be positioned appropriately.

Pedagogical aspects

Features of the pattern pertaining to its pedagogical structure and driven by its learning objectives, irrespective of the technical implementation.

Technical aspects

Technological requirements derived from the pedagogical aspects and necessary for their success.

Diagram

When appropriate, a diagram should be added to elucidate the solution. In contrast to the illustration, which communicates at an intuitive or metaphoric level, the diagram is like a blue-print for implementation.

Related Patterns

Note hierarchical, structural and lateral links to other design patterns.

Uses (makes use of)

Patterns used as components by the present pattern.

Used by

Pattern which use the present pattern as a component.

Extends

Patterns at a higher level of abstraction, elaborated by the present pattern.

Extended by

Patterns at a greater level of specificity, elaborating the present pattern.

Conflicts

Patterns excluding, excluded by or otherwise clashing with the present pattern.

Associated

Patterns used in conjunction with the present pattern.

Support

If the solution is the claim, then the support section is its theoretical and empirical substantiation. This section is not common in non-scientific uses of design patterns, e.g. in software engineering pattern languages. Where a partial equivalent would be the “known uses” section. The latter is however more in way of demonstration than evidence.

Theoretical

Theoretical alignment justifies the pattern by reference to domain theories.

Empirical

Empirical calibration justifies the pattern by reference to data from cases where it appears to have had a positive effect. These would primarily be derived from the design experiment at hand and supplemented by external documented cases.

Liabilities

Liabilities are the potential negative effects and points of failure associated with a pattern.

Risks

Risks refer to possible direct negative side effects. These need to be averted, often by applying a related pattern.

Limitations

Limitations note the patterns shortcomings, setting the readers expectations in perspective, and highlighting the additional conditions needed for this pattern to be effective.

Notes

Additional comments, reflecting on the pattern at a theoretical level or linking it to related work.

Potential extensions

Conjectures as to how the pattern could be extended and further developed to provide better results or cover a broader context.