Part one of Design Patterns: a conversation about defining and sharing user interface design languages.
What do we mean by "design patterns"?
Martijn van Welie Design patterns describe solutions. Solutions that we know can work ‘positively’ for specific problems in specific contexts. The solutions are documented as a ‘pattern’ where all aspects can be described, even implementation issues if that is helpful and relevant.
The nice thing about explicitly relating a solution to a specific problem and context is that patterns are nearly always in ‘the grey area’; they are never totally good or totally bad. When I first started writing patterns I was more thinking black-n-white about solutions and didn’t document certain solutions. Even pop-ups are good under certain circumstances. One of the most difficult things to nail down when writing patterns is finding out when the pattern actually works well. Take the pop-up example, under which conditions does it work? When you want users to be able to take a side-rout while still keeping their current task at the back? Or for provide help? Or...? Not easy to nail down well....
Besides being grey-area-stuff, patterns are (or should I say, ‘should be’) very practical. That means that the solution should be so clear to the reader that she can apply the solution without the need of further (relevant) clarification. Therefore, patterns that have solutions that feel like ‘homework’, such as “Make sure X is clear to the user”, and to which anyone who has to apply the pattern will ask ‘yeah, but how do I do that?’, are not a very good patterns. At least, that is my view.
One thing that has kept me thinking for already a while is how patterns related to guidelines or principles. Regarding guidelines it feels to me that if patterns are in the grey-area, guidelines are usually more clearly black or white. Guidelines generally do not list any context nor specific problem and seem to be a ‘general truth’. So if you’d try you could write guidelines disguised as patterns, for example “Direct Feedback”. I definately made this mistake myself. I’ll leave it to the reader to find the patterns I wrote which are not really patterns but more like guidelines....they are still online!
Regarding principles, the situation is a bit more difficult. If you look at literature on this you will see that there are tons of different kinds of principles listed. I am personally interested in understanding which principles are rooted in human behaviour that can explain why some solutions work well, or why some UI’s don’t work well. For example, people seem to have the tendency to prefer working from overview first and then refining/selecting singular element rather that directly trying to address the element of interest. Perhaps this can explain why patterns such as ‘list builder’ and ‘directory navigation’ work generally well. Jenifer mentions cognitive schemas that may underly a pattern which is probably very close to what I mean with ‘principles’.
One other issue that has bothered me is the phrase ‘solutions that work well’. Compared to what? Compared to other solutions? If so, which other ones? Naturally, this relates to the topic of providing ‘evidence’ that the pattern works. Although I would love to see it, I have yet to come across convincing evidence. Even usability test material is usally not good enough since most of the times the test do not involved comparitive testing where only 1 variable was changed.
Nevertheless, I am not too worried about the evidence issue. Last year I bought a 50 year old book which was a manual for carpenters. It listed, per topic, which different solutions could be used for a problem. For example, different mechanisms to attach a door to a frame, or legs of a chair. For us Interaction Designers (or whatever you call yourself) it is good to have an overview of all the ‘tricks of the trade’ and what makes them work and when. This is basically my attitude in developing a pattern collection. Anything that ‘feels’ like a solution to me I will try to write up as a pattern. When I have written it down it mentally becomes a ‘new concept’ in my design vocabulary. The more concepts I know the better I can do my work as a designer...
Bill Scott I got my first exposure to design patterns in the software architecture world. The Design Patterns book by the “gang of four” helped formalize my quest for capturing design solutions. This of course pointed me back to the seminal work of Christopher Alexander who first proposed the terminology of design patterns in his 1977 book, A Pattern Language. In it he defined patterns as “a solution in context of a problem.”
Alexander actually defined these solutions in a much broader manner:
“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” -A Pattern Language.
This view patterns as a “timeless way of building” rather than a defining a very specific proscriptive solution.
A good example of this type of design pattern is Jenifer Tidwell’s Overview Plus Detail pattern (also known as the Organizer pattern by Alan Cooper or micro and macro readings by Edward Tufte.) By placing an overview pane next to a pane revealing detailed information about the currently selected item in the overview panel, a user is able to explore hierarchical data and understand it in context. This pattern is common in mapping systems (small inset panel showing overview, large panel showing zoomed in view), desktop file systems (left pane shows folders, right hand shows content), email applications (left pane shows categories of messages, right pane shows message list, bottom pane shows message detail), and many other scenarios.
General patterns like these describe “the core of the solution” and in such a way that you can use the “solution a million times over, without doing it the same way twice.”
But I also believe that design patterns can be defined in a very proscriptive manner. And on this point I completely agree with Martijn’s very pragmatic view of patterns.
In the Yahoo! Pattern library we describe the Drag and Drop pattern. It is generic and can be applied it lots of ways. In fact we avoid defining a specific solution but instead provide lots of rationale and guiding principles for creating drag and drop solutions. But when we describe the Drag and Drop Module pattern we get very specific. Here we describe a solution for dragging and dropping module portals on a web site.
Like Martijn, I have struggled with this tension between patterns as a language and patterns as a detailed prescriptive solution. It is somewhere along this continuum of design principle (most generic) down to guideline (most specific) that we will find design solutions and define them as design patterns.
Sometimes our patterns will naturally catalog a timeless principle with only a partial framing of solutions. At other times patterns will emerge that due to common practice have much more specific solutions. These types of patterns look more like a style guideline rather than a timeless principle. But I believe that is OK.
I believe it is this tension that makes writing design patterns so challenging. At one hand we want to call out a “timeless way of building” and on the other hand we want to provide specific guidance to crafting a prescriptive solution in context of a user’s needs.
Design patterns are an excellent way to capture the best design principles and practices that solve real user needs.
The Conversation Continues...
Check out part two of Design Patterns