Part three of Design Patterns: a conversation about defining and sharing user interface design languages (be sure to check out part two first).
What do we mean by "design patterns"?
James Reffell “You're pirates. Hang the code, and hang the rules. They're more like guidelines anyway.” – Pirates of the Caribbean
Terminology can be tricky stuff. At eBay, we had a long history of talking about design guidelines, design principles, reusable design components, frameworks, templates – and probably about a half dozen other terms, all related, all with a slightly different emphasis or connotation. While this semantic messiness probably reflects the reality of the field pretty well, in practice it actually caused a great deal of confusion with harried designers, e.g.: “Is it a guideline we can make exceptions to, or is it a principle?”
Finally, we decided to cut through the confusion and use a single, general term: design patterns. We chose it because it seemed to convey what we wanted to build: solutions that were specific enough to be practical, but general enough to be useful in multiple situations. It seems to have worked pretty well.
So what is a design pattern? We’ve used one definition: “A design pattern is a repeatable design solution, that’s been tested, reviewed, and verified.” I think the essential part of that definition is the “repeatable design solution” part – we’ll talk about some of the challenges with testing, reviewing, and verifying later in the conversation. But repeatable solutions give a pragmatic answer to the question: if it’s a solution that’s been useful in more than a few situations, it’s worth writing up as a pattern. If it’s been documented well enough that another designer can use it for a different problem, it is a design pattern.
Which makes sense. George Lakoff would probably tell us that if we’re trying to define what we mean when we say “design pattern”, we’ll have better luck coming up with prototypical examples than with trying to find definitions with clear boundaries. So I’ll give that a shot and will pick out a few examples:
- The Two-panel selector from Jenifer’s Designing Interfaces
- Interdependent form groups from widgetopia:
- Autocomplete from Yahoo’s Design Pattern
While we could (and should!) critique various aspects of these, to me they are what I mean when I talk about design patterns. And if we continue to point out, use, and critique patterns like these, then through that discussion we’ll get a better idea of what design patterns really are.
Finally, I think we (interaction designers and other designers in newer media) have to have a little humility about our field and our patterns. As has already been pointed out, discussion of design patterns originates with Christopher Alexander. While the essence of Alexander’s theory makes as good sense for what we do as for what architects do, there is a difference: he based his patterns on things humans have been designing and building for thousands of years. While some of the principles are the same across any media, people weren’t designing for 2D animated screens on mobile devices in 1400 AD. Our field has a little more learning to do before we could hope to call anything we do timeless.
Martijn van Welie I agree with James in that our field is still very new, especially when compared to architecture, and we should not have the expectation that we can easily come up with ‘timeless’ patterns yet.
Some designers are ‘afraid’ that patterns dictate how they should design, or that they will become less creative. Luke formulates a similar concern but I do not think there is any reason to worry. Designers must design an entire interface and I do not see how using knowledge about how to solve small design problems would lead to sub-optimal interfaces. Nevertheless, if there is no pattern that can help you when you are solving a design problem, you will still need to solve the problem and be creative. At least you don’t have to put your energy in re-inventing the wheel again.
Bill Scott The other interesting aspect to design patterns is they form “bite-sized chunks” of best practice. This allows patterns to be more accessible to a wider audience (since they are more likely to be read) forming a pattern language or vocabulary.
Jenifer points out the teaching aspect that a pattern library provides. I have found this to one of the most beneficial aspects to pattern libraries in general.
At my previous employer, my user experience team worked with a couple dozen different products. In performing heuristic evaluations and providing new designs we quickly saw a few general patterns emerge that we used over and over again. I took this small set of patterns (organizer, master-detail, workbench, etc.) and put together a small workshop teaching them to our engineering and product marketing teams. I used this language in all discussions with marketing. Each time I used the terminology for the first time I would take a few minutes to explain the general principle. Before long we had both engineering and product marketing using the same language. They would often sketch up ideas and express them in terms of these patterns. Sometimes the application was not correct but it always gave us a chance to discuss the nuances and choose a different approach as necessary.
At Yahoo! I spend a lot of my time evangelizing inside and outside the company ways to use rich interactions on the web. My lingua franca is a set of core design principles illustrated with a set of design patterns that have been emerging on the web. These workshops and sessions have been extremely well received. I believe one of the reasons is the bite-sized chunks are much easier to digest than a design guidelines site.
I have never forgotten a story that Robin Williams, author of the Non-Designer’s Design book, told about the power of naming things. Visiting her parents during the holiday season, she received the gift of a tree identification book. Looking through the book she noticed an unusual tree and wondered if she might find one of these in her neighborhood. Walking outside she immediately spotted not just one but a neighborhood full of “Joshua Trees.” Being raised in Southern California you would have thought that she would have noticed them before. Only after seeing the example and having a name for the prototype tree did she then spot them everywhere.
That is one of the real powers of these patterns. They not only expose a solution but they give it a name. They create a classification system. They form a vocabulary, a language. They provide a way for people to talk about the concept and a way to recognize the solution when a similar problem context arises in the future.
More to Come
Check out part four of Design Patterns