Article: The Elements of a Design Pattern
January 24th, 2006
UIEtips 1/24/06: The Elements of a Design Pattern
Since we first talked about them in 2003, Design Patterns have become a popular method for teams to tame the consistent-design-management tiger. We’re seeing many of our clients turn to an in-house built pattern library to help them coordinate a consistent look while allowing innovative design to appear as required.
Building a library takes a lot of work, especially at first. However, unlike standards and guidelines, organizations can distribute that work across all members of the design team. Our research has turned up informal techniques, where teams hold a lunch party where each written pattern buys you a slice of pizza, to formal review techniques, like those employed by the folks at Yahoo! (See the excellent Boxes and Arrows case study.)
We’ve been very interested in how various clients are going about building out their libraries. In this week’s UIEtips, I recount some of the more interesting pattern elements we’ve come across. If you’re thinking of building out your library, this could help you get started.
Are you building a design pattern library? What are the elements that you like the best? Share your thoughts in the comments below.
Read the article here.
Christine Perfetti and I will be discussing design patterns in the Effective Dissemination portion of our upcoming UIE Roadshow tour. If you haven’t registered for this, you may want to do so very soon — Seattle is on the verge of selling out and the other cities are filling up quickly. See the details at the UIE 2006 Roadshow site.
January 24th, 2006 at 6:11 pm
While writing my patterns book (”Designing Interfaces: Patterns for Effective Interaction Design,” O’Reilly Media), I eventually settled on these pattern elements:
* Name
* Primary example — a screenshot or photo which captures the pattern perfectly
* What — a soundbite description; if I can’t capture it in one or two sentences, is it a pattern worth putting into the book?
* Use When — the context of use
* Why — an explanation of the design principles underlying the pattern
* How — advice, suggestions, pitfalls, alternatives, and related patterns
* Examples — an assortment of diverse examples that illustrate the range of the pattern; critical for visual thinkers
This simplified structure went over better with the intended audience than the more Alexandrian structure I had used in a previous iteration. A very few people have asked for additional sections — “Related Patterns” being one — but the information’s already there anyway, usually under “How.”
And yet I don’t think your long list of section names is wrong. Why? Context of use, of course!
I wrote these patterns as a teaching tool and a brainstorming aid. They were not a collective, collaborative effort; they do not represent the history of a single organization’s design work. If they did, then I’d agree that sections such as Specifications, History, Code, and especially Usability Results would be very important indeed.
Still, a long document can be scary-looking. If you want your patterns to be read by as many people as possible, I think you shouldn’t overwhelm them with five pages’ worth of stuff. Put the sections most important for hurried readers up front; hide the rest behind another link or something. As described in the “Extras On Demand” pattern, of course.