This is the final article of a five-part series on communicating design patterns. When James Reffell wrote this piece, he was the pattern curator for the eBay pattern engine. For more background on design patterns, you can read an earlier five-part conversation answering the question What are Design Patterns?
Q: What’s the best way to communicate a pattern?
I’m constantly amazed at the power of design patterns to communicate. I’ve found that a well-described pattern can both convey both a specific solution (which can help me solve a difficult design problem) and the core interaction principles that underly all good patterns (which can help make me a better designer).
While designers will probably always be the primary authors of and audience for design patterns, I’m finding more and more that they’re useful in communicating with all sorts of folks. These include not only the developers who are responsible for building our designs but also the business folks, product managers, and other non-designers. There’s also a big difference between talking to other designers inside an organization (as with eBay or Yahoo’s internal pattern libraries) and talking to a more general design audience (as with books or the public libraries).
The core pieces of information – What, Use When, Why, How, and Examples – are necessary to tell the story of each pattern for all audiences, and Who becomes a big deal in an internal library. Users of an internal library might also find links to internal design standards and specifications useful, as well as a list of places where the pattern appears. Additionally, as Bill points out, if the pattern will be used by a specific developer audience, the How and Examples might add sample code and implementation details. Since patterns aren’t exactly built in stone, it’s also helpful to add things like ratings, discussions, links to similar patterns, and the like.
Once you’ve added all these additional pieces of information you have something that’s grown well beyond just a design library – and that’s OK as long as it works for the intended audience, and as long as those first core pieces are in place!
So much for the parts of the whole. I think it’s also important to look at the pattern description as a whole and coherent story, however. Narrative is an important tool for communication, and I think we might not take advantage of it enough – some pattern descriptions can get a little clinical. I prefer to see the examples rounded out with some history—and maye some drama and a few laughs! There’s no harm in telling how we came to realize a given pattern was a good solve, the bumps along the road, the other things that we’ve tried and have failed entertainingly. Why can’t a design pattern also be a ripping good yarn?
Finally, the designer in me thinks we should maybe take a little of our own medicine here. Design patterns are primarily tools for designers, and we should design them accordingly. One of the things that impressed me with the Yahoo pattern group’s work is that they worked in some good design methodlogies when building the library—I’d love to see more work along those lines. Does anyone know of other examples of user testing for our pattern libraries?