Patterns are a systematic way to capture the experience of experts about good or best practices and document these nuggets of wisdom in an accessible way for designers. Patterns are appreciated by academics and practitioners alike because they describe and reason about good designs in a way that makes it possible for others to understand and reuse it.
The pattern approach has its roots in the work of the architect Christopher Alexander who has developed a pattern language about towns, building and constructions. He captured whole forms of meaningful designs and connected them into a language. Alexander provides a basic definition of patterns:
„Each pattern describes a problem which occurs over and over again in our environment, and then describes
the core of the solution to that problem, in such a way that you can use this solution a million times over,
without ever doing it the same way twice.“ (Alexander et al., 1977)
Patterns are rules that express a relation between a certain environment (context), a problem (conflict of forces) and a solution (resolution of the conflict). They describe recurrent designs on a medium level of abstraction. To use a solution “a million times over, without ever doing it the same way twice” implies that the description needs to be generic and adaptable to new situations. This makes the pattern approach interesting for academics because they can find general rules and reasons for the relations. At the same time patterns are specific enough to grasp the gestalt of a solution and provide generative directions how to build it. Practitioners appreciate that patterns have practical relevance, help to build better, human-friendly solutions and provide insights into non-trivial problems.
While patterns have started in the field of architecture, the approach is beneficial to all design disciplines. The community of object-oriented software designers has first adopted the approach. Richard Gabriel suggests the following definition for the field of software design:
“Each pattern is a three-part rule, which expresses a relation between a certain context, a certain system of forces
which occurs repeatedly in that context, and a certain software configuration which allows these forces to resolve
Buschmann, Henney, & Schmidt (2007) summarize in “Pattern-oriented software architecture. Volume 5: On
patterns and Pattern Languages” the common core properties of patterns
and pattern languages:
- Each defines a process and a thing.
- Each ensures that the ‘thing’ whose creation it supports is of proven and sound quality in its structure, behaviour, and core properties.
- Each explicitly addresses the forces that can influence the concrete look-and-feel of the designs and the character of the environments that it helps to build.
- Each supports genericity by describing entire solution spaces, not (just) single point solutions.
- Each enables communication, discussion, and dialog about its subject to aid understanding of the nature, forces, and consequences of the solution presented.
- Each has a concrete name so that its audience can remember it and immediately know what subject or domain it
- Each is a work in progress that should constantly be updated toward new and evolved experiences and knowledge in its subject domain.
- Each can be implemented in many different ways without ever being ‘twice the same’ – dependent on the concrete requirements, constraints, and scope of the systems or environments in which it is applied.
The software community also started to document pedagogical patterns. The Pedagogical Patterns Project writes:
“Patterns are designed to capture best practice in a specific domain. Pedagogical patterns try to capture expert
knowledge of the practice of teaching and learning. The intent is to capture the essence of the practice in a
compact form that can be easily communicated to those who need the knowledge. Presenting this information in
a coherent and accessible form can mean the difference between every new instructor needing to relearn what is
known by senior faculty and easy transference of knowledge of teaching within the community.”
Today patterns have been written for many design disciplines, including business, organizations, human-computer-interaction, web design, online communities, e-learning and game design.
While there are many different description formats, a good pattern should always capture the following components:
The situation in which the solution is applicable. The context describes the conditions under which we find a problem that can be solved by the pattern. The key to describe the context is to ask when-questions. When can this pattern be applied? When should it not be applied? Which other patterns have led to this context?
Problem and forces:
This section describes the problem that can be found in a certain context. It reasons about why something has to be done and why it could be done in the specific way described in the solution. The key to describe the problem and forces is to ask why-questions. Why do we have to follow this specific solution? Why do we need this specific form? Why can’t we do another thing instead? Each single force gives another answer to such why-questions. A force explains the cause for a specific design decision by giving the “because” to the “why”.
The solution describes how the problem and the conflict of forces can be resolved by a specific structure. The key to describe the solution is to ask what-, how- and who-questions. What is the general structure of the solutions? How can I generate the solution structure? How do the parts relate and interact? Who is participating in the solution? What are variations of the solution? Many pattern authors first provide a brief summary of the solution form (what the solution is about) followed by implementation details. Examples can illustrate the whole solution or parts of it. Known uses refer to empirical evidence that the solution has worked in actual projects.
This section reasons about the impact of applying a solution. It describes the resulting context, benefits, costs, drawbacks, tradeoffs and liabilities of the solution. Which forces have been resolved or weakened? Which forces remain or have been newly introduced? What needs to be done next and which other patterns could support this solution?
Pattern authors often use different names for these sections or split one component into several sub-sections.
Want to write your own patterns? Get started here!