Do pattern libraries really work?

I wish I could have been at the recent Chicago IxDA Pattern Library conversation, a participatory discussion about using pattern libraries in practice.
I appreciate the shout-out for the open Yahoo! pattern library and I welcome the questions about how our non-public-facing library actually works. In fact, I am currently putting together a brown bag talk I’ll be giving in Sunnyvale tomorrow to catch up and fill in our own user experience designers on what’s new in the pattern library, what have we changed, what have we learned, what’s been working, what hasn’t been working, and how they can contribute and get the most out of it.
While this is an internal-facing talk, I believe the camera guys from the Yahoo! Developer Network will be filming it so as long as I don’t slip and give away our secret plan to equip everyone on the planet with a jetpack (oops!) there might be an opportunity for the interested general public to see the talk.
In Chicago, it sounds like they raised all the right sorts of questions:
> Are we confusing pattern with component, pattern library with style guides?
>
> Is a lightbox a pattern or a solution, or is that one and the same?
>
> How do we have a group of people come to a consensus on what should constitute a pattern?
>
> How do we justify the time spent in creating the resource?
>
> Does this need to be tied back to code to be efficient?
>
> How do we institutionalize its use? Here you create this thing… does it die the minute you look the other way?
>
> Should an agency have one? How would that work across clients? Could it be high-level enough to be useful?
I think the answers to many of these questions are situational. There’s an interesting tension between pattern-language purity and practical usefulness. In my experience a working pattern library has to straddle that line between enshrining time-worn principles and providing handy reusable components.
I think a pattern library can be considered a sort of style guide, although the discipline of expressing patterns as solutions to problems in context takes it away from the more changeable, spec-oriented, visual-centric style guides most of us are familiar with.
The granularity question (lightbox? slider? carousel? etc.) needs to be answered in context. I’d say whatever works for the people who have to actually use the library is what you should do. Don’t get too hung up on semantics and purity.
Building consensus is probably the most interesting challenge, although of course it depends on the size and structure of the organization in question. This is something I plan to address at several conferences over the next year (organizers willing).
Justifying the time spent on the resource has to be based on time saved and efficiencies realized in the future. If you can’t get that “return on investment” it’s frankly not worthwhile to put together such a resource. However, do carefully look at what time and efforts are being wasted if a large team keeps designing the same interactions over and over.
Wherever possible, I think patterns should be tied back to code. I don’t consider the code samples to be part of the pattern language proper, but I think the best patterns are augmented by many visual examples (including animations), interaction and visual specs, code samples, reference implementations, prototypes, and templates and stencils for rapid reuse. You won’t always have all these elements available but the more the better.
I’ll leave the agency question for the community to discuss. I suspect it would have to be fairly high level to work at all. But then again what agency doesn’t reuse some tried-and-true wireframes or other conceptual documents and diagrams?
Janna Hicks DeVylder wrote on the ixda list, “It’s clear that people are interested in this, but it feels like we want to see its utility proven out past just the creation of the library. I would love to hear about the successes and challenges Yahoo has faced with their non-public facing library. Sounds like a great conference topic to me!”
I agree! I have a panel on this topic (Pattern Libraries: The Devil’s In the Details) under consideration for South by Southwest. The panelists include Austin Govella and Jenifer Tidwell. I’m also about to propose a slightly different talk with Austin for the IA Summit, this one focused a bit more on the information architecture and social organization of pattern libraries (for effective use). In both cases I will be drawing on the lessons we’ve learned at Yahoo: what’s worked and what hasn’t and how we’ve changed course and refined our ideas to continue building consensus around a core library.
I’ve also got a lightning-session proposal submitted for Interaction08 where I will talk about a new wave of social media patterns (and toolkits – a concept I’d love to explain further) we’re currently incubating in our internal-facing library.
I blogged just recently here on the “bastardization” as Janna put it, of the pattern term. I understand why it’s happening (and in general I am more of a descriptivist than a prescriptivist when it comes to language use), but I will probably continue to speak up for the idea that to be called a design pattern something must at the very least be described in terms of context, problem, and solution.
Lastly, I want to note that I think the consensus from Chicago is dead-on when addressing the role of patterns in innovation. Patterns are inherently not about innovation. They are about tried-and-true dependable solutions. What they do is free the designer up to create and innovate on the leading edge of the design problem, without having to dedicate as much energy to “reinventing the wheel.” Inevitably, we will all end up retracing each other’s steps frequently as we learn to design, but whenever we can learn from the successes of the past, I think it behooves us to do so.