Design Patterns are a Process and not a Product

Richard N Griffiths

University of Brighton, UK
School of Computing and Mathematical Sciences


This submission addresses the process of developing design patterns in HCI. I will argue that whilst the concepts of design pattern and pattern language have apparently obvious beneficial application in structuring and representing guidelines in a tractable and generative form, this takes account only of a shallow aspect of the pattern language programme. There is a deeper and more thoroughgoing aspect that should be explored in this domain.

With a romantic metaphor in mind, I would say that my relationship with HCI pattern language has just come out of the infatuation stage, and I'm starting to look critically to see if there really is a future for us. I get the sense that I am not alone in this. (That's one of the advantages to being a workshop facilitator — you get to read everyone else's position paper before finally editing your own.)

Here are the superficial appearances that hooked me into my relationship with patterns: The idea of casting good practice in interaction design as design patterns appears to have significant advantages over the writing of guidelines:

These are the ‘neat ideas’ of the sort that Alexander has castigated the object-oriented community for not having got beyond. However, there is a down side: Each of the claims above are subject to considerable qualification and may be disputed. In principle, they could be subjected to empirical evaluation (and this is something that the patterns community could do). However, I'm now beginning to see that they miss much of substance that is contained in the pattern language concept, and which would not be easy to quantify or evaluate. This involves acknowledging the deeper aspects of designs that are appropriate and amenable to sustainable human purposes.

It may well be the case that the form of design pattern and pattern language can be useful in interaction design without consideration of these other aspects. They would encourage consistency and standardisation of design and thereby assist in managing the design process. For example, the ‘pattern’: "Make everything look like it was designed by Microsoft" considerably simplifies the design process, and appears to produce acceptable results. (That's certainly the implicit guideline that most of my students adopt naively.) So simply casting existing design guideline sets into pattern form could usefully be done. Maybe the Microsoft style guide could be rewritten as a pattern language to generate Microsoft clones. It could even be automated as a Wizard! But much would be missed. For design patterns to make a significant contribution to human well-being, they need to point to timeless solutions — and there's the problem: where are timeless solutions to be found in this domain?

It seems to me that there are a number of sins of omission and commission that we should seek to avoid as we take the idea of HCI pattern language further. I don't expect that my list is exhaustive.

The sin of hasty codification

It is a key aspect of Alexander's development of patterns that they be based upon existing examples. In the case of architecture the accumulation of examples has been proceeding for millennia, and unsuccessful design details have been winnowed out over successive generations. In the case of computerised information system design, and the design of their human interfaces, this process has hardly begun, and any ‘patterns’ drawn from this experience may be insubstantial and ephemeral. Further, rapid codification as a design pattern may be positively harmful, as it could perpetuate a less that optimal design solution — the interface design equivalent of Qwerty keyboards, a status that Windows™ has already obtained.

The sin of mistaking the map for the territory

As well as the issue of the pattern concept being trivialised, there has been another problem with my (our) understanding of patterns. There is a danger of mistaking the map for the territory. It is important to remember that the pattern exists independently of anyone writing it down as a design pattern. Where it exists is an interesting metaphysical speculation! It may be in craft knowledge — which may be the procedural knowledge of creators (designers and constructors) in the domain, or it may have a Platonic existence awaiting discovery through mathematical or other scientific analysis. However it may only be identified at the intersection of constructed artefact and social use. The point being that, to use a metaphor from chaos theory, the pattern is an attractor that the written design pattern points to but that, I would suggest, in all but the simplest cases can never completely define, i.e., it is a strange attractor. This has a practical implication: it is inappropriate to attempt to create the canonical set of design patterns. Every attempt to capture a pattern will emphasise certain aspects and attenuate others. However, recognising that one design pattern points to the same underlying pattern as another is valuable, if problematical, and requires identifying the pattern by a common designator. Design patterns may be used by design practitioners to negotiate a shared appreciation of the pattern.

The sin of fetishising the form of a design pattern

There is also a potential problem of our fetishising the superficial form of a documented design pattern. Not everything that looks like a design pattern captures a pattern, and understanding how to capture a pattern from our domain is a problem. An issue relevant to this came up at the end of the Interact’99 workshop when a group of us were finalising the poster we were required to produce. (See: ) We had decided that the best way that we could get across the idea was to give an example HCI pattern. We used a variation of Alexander's form, with a schematic illustration at the end. In Alexander's design patterns, these are schematic architectural drawings. (Alexander specifically refers to them as diagrams.) Is this the appropriate form for the schematic illustration of interaction patterns? In the event, our example pattern contains two schematics; a sketch, and some lines of pseudo-code. Which is really in the spirit of Alexander's patterns?

I got some insight into resolving this when I read Alexander's ‘Notes on the Synthesis of Form’. (You often get key insights by following the genesis of an idea back through a writers work.) There the significance of the diagram is explicated at some length. He categorises diagrams into form diagrams, which "... summarise aspects of a physical structure, by presenting one of the constituent patterns of its organisation ...", and requirements diagrams, which "... summarise a set of functional properties or constraints, ... This kind of diagram is principally a notation for the problem, rather than for the form." He stresses that diagrams should be ‘constructive’, by which he means that they should be both a requirements diagram and a form diagram in one, and that it should "... help in effecting the translation of requirements into form ..." The example he gives is a vehicular traffic flow diagram, in which the density of traffic in a particular direction is signified by the width of an arrow. Ceteris paribus, the road layout to accommodate maximum traffic should look like the diagram.

It appears that in our example pattern we managed to produce a form diagram (the sketch) and a requirements diagram (the pseudo-code). But how should they be put together to create a constructive diagram? What does a constructive diagram in our domain look like? As we are freed from many of the constraints of material construction, and may wish to document patterns that have no immediate material realisation (e.g., processes of group co-ordination of work) using the same notion of form that is appropriate to architecture may be too narrowly prescriptive in our domain. I.e., it will emphasise one amongst many potential material forms (widgets on screens) of realisation of the pattern.

The sin of only recognising the theoretically appropriate

If Alexander's idea of pattern language grew out of the ideas explored in "Notes on the Synthesis of Form" (NotSoF), then it might be worth examining that book for ideas on the deep issues we may have to confront when creating design patterns in our domain.

NotSoF contains a methodology for developing a design out of an analysis of requirements. Essentially all requirements (and there may be over a hundred for a realistic design problem) are analysed to identify those that support each other, and those that conflict. This is used as input to a partitioning algorithm that breaks the collection into strongly internal but weakly externally interacting groups and subgroups. The resulting tree of grouped requirements is used to modularise the design space. Constructive diagrams are produced to provide solutions for the leaf subgroupings, and then composed (in the mathematical sense) to solve the requirements in their super group, until the whole design arrives as a composition at the topmost level.

An emergent property of Alexander's analysis is that the groupings of requirements do not correspond to the typical analytical categories that designers may use to discuss the domain, e.g., function, economics, production, safety, use, capital, maintenance, etc. His argument (based on the Whorfian hypothesis) is that designers who attempt to use these categories are inevitably lead away from appropriate solutions.

"In this fashion the selfconscious individual's grasp of problems is constantly mislead. His concepts and categories, besides being arbitrary and unsuitable, are self-perpetuating. Under the influence of concepts, he not only does things from a biased point of view, but sees them biasedly as well. The concepts control his perception of fit and misfit — until in the end he sees nothing but deviations from his conceptual dogmas, and looses not only the urge but even the mental opportunity to frame his problems more appropriately." It appears that patterns are to be identified in the solution of these design module complexes of interacting requirements. Hence, it may not be obvious where a pattern ‘came from’, i.e., what interaction of principles are required to explain it. Some of the patterns in "A Pattern Language" are like this. For example, "116 Cascade of Roofs" which contains the comment: "Why do these apparently different problems lead to the same pattern? We don't know. But we suspect that there is some deeper essence behind the apparent coincidence. We leave the pattern intact in the hope that someone else will understand its meaning.’ Can we identify patterns in the myriad of interaction design solutions that are thrown up, by not looking in ways that cause us to be blinded by our conceptual dogmas?

So how forward?

So how should the development of interaction design patterns proceed? I would suggest that this should be done at several levels, acknowledging the relative ephemeral /timeless status of the design patterns that we propose. When we are structuring current good practice as design patterns and pattern language we must be aware that this is a shallow and intentionally ephemeral use of the idea. At the same time, we should have one eye on the bigger picture, and look for timeless patterns to incorporate in our design, where the design pattern pointers to these patterns may not have been generated within the software domain.*  For example; in architecture, in the structure of books, libraries, paper filing systems, the practice of typography and graphic design, painting, furniture design, agriculture, civil and mechanical engineering, ... I.e., where a class of designed artefact has existed for many generations, and the practitioners of the design of that type of artefact undergo a craft apprenticeship, in which the mysteries of the craft are transmitted to successive generations of practitioners. Or more abstractly, there must be an environment in which the pattern may evolve (perhaps, after Dawkins, as a meme, evolving in the Darwinian sense).

It may be argued that as the pace of industrial development has hotted up — and the software domain must be the quintessential example of this, the rapid turnover of designs means that the evolution of substantial patterns may occur within the working lifetime of one generation of designers. Against this, the frontiers of use of the new technology are rolling back at a phenomenal rate, with new developments appearing on the horizon before current designs can be fully assimilated. A contemporary example of this is the arrival on the scene of e-commerce via interactive television, while the existing mode via the web, has not been fully established, and other possibilities via mobile devices are waiting in the wings. In this tumultuous environment, it may be unrealistic to expect to identify substantial and persisting patterns, but on the other hand, the attempt to do so may represent the only way to get a principled grip on the requirements of good design. Thus engagement in the process of searching for patterns may be much more valuable than any design pattern that we may produce.


Brighton, February 2000

*This may already have been acknowledged within interaction design practice by the adoption of metaphor as a guiding principle.  However the literal application of metaphor has been substantially discredited.  The idea may be worth revisiting, with metaphor applied in a more abstract way, as similes, through the application of patterns obtained from other domains.