First, any of us who have been in the business know the patterns and a quick google search will provide you with more thoughts and examples on the subject than you could ever imagine.

Second, they’re not for us but we’re tasked with creating & maintaining them.

Third, if you don’t know the functionality of the basics and when to apply them properly (radio button v. checkbox), you shouldn’t be making those kinds of decisions. Period.

I used to write detailed functional specifications and storyboards for my teams and they were incredibly effective. What has happened? It seems that in an effort to keep re-inventing the wheel, we’re making more work for the teams and creating more swirl.

We do need documentation, but once a pattern is designed and applied, it is a living, breathing example of how to do it right – unless no one listens to ux and does it wrong. In that case the pattern “whatever” doesn’t matter anyway… This is especially true in the application world.

I think the bigger issue is integrating ux into the development process and allowing us to collaborate with developers to make sure they apply to designs properly.

If a library doesn’t support code reuse it’s a sign that UX & engineering aren’t really working together as a team (and management isn’t making it happen). Sadly as a consultant, I still see companies that fail at this all the time. Teamwork is the real secret ingredient behind all great UX…there is no substitute.

Here’s a tip. if you include an example on the pattern page that uses the latest code, it removes the problem of updating things later on. It also has the added benefit that you know if there’s a delta between “as spec’d” and “as built”. Putting the example UI next to the image/spec makes it easy for the entire team to verify the pattern exists and to test it.

A critical part of this approach is that it stay a living document similar to a wiki approach. Someone has to initially get the bones of the structure running but once that is in place, it’s a valuable resource in large teams (especially geographically challenged ones) to make sure we’re all doing functionality as consistently as possible within the scope of the requirements. You can’t have two calendars that behave or look like it wasn’t made by the same team or belong on the same site.

Developers should not be using the pattern library. A UX Designer worth his salt would never tell a developer to go refer to an internal reference document. UX should be providing developers with a working wireframe for the feature being developed using the pattern library as a resource from which that wireframe was built.

As you wrote, there seems to be an assumption that a pattern library has to be a dictionary. I agree wholeheartedly that most people can’t learn a language by referring to a dictionary. However, when a teacher (UX) uses a dictionary (pattern library) to teach students (development) the context and common definition of a word, it’s an invaluable resource. Can you imagine a world without dictionaries?

As contrast: In a recent project we designed over 80 design patterns (and no fluff ones like “Radio Button”). These were only lightweight specced which we then took to devs and did some agile rapid prototyping iterations and refining of the specs before they went off and produced code modules. Importantly, this was a special dev team set aside to produce code libraries which the app devs would go on to use.

Note too that we didn’t just hand over all our wireframes and ask the devs to find patterns to code. We did consistency reviews and peer reviews of our wireframes (a necessary process in any case) and out of that process we identified the design patterns we were using. This process also encouraged us to refine and coalesce the design pattern definitions, removing some idiosyncrasies. If we didnt remove those idiosyncrasies but simply handed the wiredecks to devs to codify the apparent patterns they would of course had to code all those warts in too.

Another outcome of the UX design review and pattern definition process is that we actively participated in some uncomfortable discussions which exposed some differing assumptions about the UX vision we were theoretically hewing to. We refined the UX vision, and captured those findings into the pattern definitions as well.

Since we are building up a practice from very little previous capacity in this area, we needed a way to focus our energy and bring awareness to a completely new way of working.

Researching, discussing and documenting patterns (they start out on our internal wiki by multi-disciplinary groups) as an interesting first step to:
-building code packages that support user tasks
-communicating to the (many!) people involved in web development across a distributed network of organizations
-empowering anyone within the organization to provide potential solutions (or at least identify problems)
-providing requirements to designers and developers

The development of the patterns is just one part of a peer-reviewed process that includes usability and accessibility specialists, amongst others.

Each of the patterns in the library links to it’s corresponding code package. Our entire code repository is available online and is free for anyone to use.

You can see our works-in-progress here: http://www.tbs-sct.gc.ca/ws-nw/tmpl-mdl/index-eng.asp Comments welcomed

I think a quintessential example of a component library is Twitter’s Bootstap project (http://twitter.github.com/bootstrap/). In a recent article on A List Apart, it’s co-creator Mark Otto described their approach as making it into a self-documenting style guide (http://www.alistapart.com/articles/building-twitter-bootstrap/).

From my experience actively curating a component library at TwigKit over the past two years, the two greatest lessons I’ve learned are: design and development must collaborate as closely as possible, and iteration is vital to success.