Much like genres (see previous post: Can we describe interfaces as genres?), design patterns aim to create a classification scheme. Alexander created his methodology, in response to his feeling that designers in a post-industrial society lack the knowledge of materials and construction methods that people in a pre-industrial society have, via tradition. The slow evolution of tradition allows humans to adapt, slowly, in context, therefore identifying optimal solutions (optimal for humans, optimal for nature and the materials in use). To compensate for the lack of tradition in new materials and construction methods, Alexander described a methodology that consolidated research about human behaviour and the form that is required to support that behaviour into a hierarchical ‘language’.

He describes his methodology as a language with elements that have an explicit relationship up and down the hierarchy: in a way that the syntax of a language might work. Users of the pattern language identify the pattern (unit of the language) most relevant to their design problem (perhaps designing a house). They should look up and down the hierarchy to identify the other patterns (designing a street of houses or designing a kitchen) that also have an effect on the problem. In this way the designer can discover the entire context in which the problem sits and circumvent the lack of tradition.

Often with patterns the issue of stifling creativity is raised. Patterns are created and presented in a way that present the context, form and a high level solution to a problem without specifying the detail. Alexander went so far as prescribing the way patterns should be communicated: relying on clear labels, open descriptions and what he calls constructive diagrams (diagrams that appear in sketch format, describing the solution at a high level) to describe the pattern. Patterns can be used to speed up the design process, ensuring that designers do not reinvent the wheel with every new project they undertake. A designer can focus on adding to our body of knowledge and tackle new, more demanding problems when familiar and common problems clearly are described.

The question is whether we, as interface designers, can create languages that apply to our design problems? Interfaces have a history of only approximately 40 or 50 years; design patterns would definitely help us overcome our lack of tradition. There are reoccurring problems that occur. My opinion is that, yes, we could create a pattern language for interfaces if the focus of that language was user behaviour in reaction to a context and not specific interface layout.

Many people have created pattern languages for interfaces. Among the most referred to are: the Yahoo! pattern library and Tidwell’s Designing Interfaces. Both are interesting and provide insights that add to any design challenge. However I find them quite prescriptive. There is a lack of overt hierarchy and solutions seem to be specific where writers have chosen to include individual examples rather then stick to the high level constructive diagrams that Alexander described. I did find one example (after an inexhaustive search: other examples are welcomed) that I found to be true to his methodology and useful to me. The Design of Sites, although potentially out of date now, provides an almost hierarchical organisation scheme and describes the relationship up and down that scheme; informing the designer of contexts and reactions to them. Solutions are described using constructive diagrams, allowing for creativity.

I think that we are only beginning to conduct enough research to create a true pattern language and all interface pattern languages should be regarded as works in progress as there are many more contexts to understand thoroughly. We will get there however; it did take Alexander 10 year and he had many collaborators to provide us with his one example.