How may organizations learn?

· Events, Social Design, Teamwork

At Overlap in Asilomar last weekend, Jay Cross asked the question, “How can we improve learning in organizations?” and filmed a number of us trying to answer that question.

Here’s the just-under-ten-minutes YouTube cut:

(For my extensive roster of fanboys and stalkers, my segments are approximately 4:23 – 5:16 and 7:20 – 8:36.)

Pattern languages interview

· Design, Patterns, Teamwork, User Experience, Yahoo!

[] In anticipation of the Pattern Library workshop I’m teaching with Erin Malone and Lucas Pettinati, Will Evans interviewed us for Boxes & Arrows, the premiere user experience magazine online.
Will asked great questions and I think he brought out some interesting discussion among us all. Here’s a taste:

Question: I have heard it argued that use of design patterns and pattern libraries removes creativity and innovation from the solution-finding process? Do these criticisms have merit?

xian: I don’t really think that argument holds water. I do understand the concern, and it’s totally possible to apply patterns mindlessly or to force their use inappropriately, but, to my mind, patterns focus innovation and creativity on the leading edge of the problem: the unsolved part.

Read the whole thing over at B&A!

Help me write my book about presence

· Patterns, Social Design, Teamwork, The Power of Many, User Experience

most recent tweet
I’m going to write my book, Presence of Mind (working title), on a wiki with as much input from others as possible. I’m also starting a mailing list to discuss online presence and related topics (extending from closely related matters such as identity, reputation, attention, privacy and so on, out to the full array of social web design patterns).
If you’re interested in joining this conversation, let me know and I’ll invite you when the list is set up.

As promised, my pattern library talk

· Design, Patterns, Teamwork, User Experience

As the third curator of Yahoo!’s Design Pattern Library I often receive a lot of thanks and praise from website designers and developers for the way we at Yahoo! have offered this resource to the world. I usually try to explain that much of the goodness happened before I came on board and that I can’t really take credit for it, but when my ego needs a boost I just smile and nod.

When Erin Malone and Matt Leacock and others first launched the internal pattern library, they presented a talk at the IA Summit, called Implementing a Pattern Library in the Real World: A Case Study (and subsequently the linked article on the same topic at Boxes and Arrows). Then Erin and Bill Scott took the library to the public on the Yahoo! Developer Network website and Bill enriched the library with tons of Ajax-y goodness, closely tied to the YUI Library.

Since that time, I came on board and I’ve worked on reorganizing the library, updating the patterns, and shepherding a new generation of patterns through our internal refinement and review process, with an eye toward identifying useful social and openness patterns that we can share with the whole Web. So when people come up to me at conferences or find me on mailing lists for information architects and interaction designers frequently the are curious about how the library has evolved in the years since it was founded, what our internal process looks like these days for writing, reviewing, approving, and rating patterns, and how we decide which ones to publish in the open library.

Recently, I gave a talk at Yahoo! as part of our UED Brown bag series, called The Pattern Library Wants YOU!, intended to update oldtimers on changes and improvements to our process and infrastructure and to orient new designers about the library, and of course to encourage people to get involved. Ricky Montalvo, our ace videographer for YUI Theater and YDN Theater, recorded my talk and edited it together with my slides, and we just spent a week or so removing any too-sensitive information and getting our friendly legal folks to sign off on releasing the talk to the public.

So, without further ado, here is the public version of my talk, which should answer a lot of those questions I’m hearing these days.

(This post was adapted from the YUI blog by sticking it on a block of wood and banging a nail into it.)

Enumerating social media patterns: a work in progress

· Design, Information Architecture, Patterns, Social Design, Teamwork, The Power of Many, User Experience

thumbnail section of social media patterns graph
At BarCamp Block earlier this year I led a discussion of social media design patterns. The slides I posted were really more just about patterns and how we deal with them at Yahoo! But the group exercise was to brainstorm a huge list of social media and social networking activities that could be described and documented as patterns.

These are not the patterns themselves, but at least one pattern could probably be written around each of these gestures. We found it easiest in the brainstorm to just rattle off a list of gerunds (“adding, blocking, friending,” etc.).

The list we came up is also not exhaustive or definitive. It’s one group’s idea of the various patterns that a social system could support. The initial list was posted at the BarCamp Block wiki. Then Kent Bye, one of the participants, took a stab at re-sorting it a bit and created a visualization. He also then hand-copied it into an outline format and sent me his “version two” of the list.

Since then I’ve made a few more tweaks and have produced a version 3 outline. I’ve been working on visualizing it myself, so I turned the OPML into an OmniOutliner file and then imported that into OmniGraffle. The map is so tangled that Graffle had a hard time displaying it without crossing lines, so I spent some more time dragging the various nodes and clusters around until they were each separate. The end result is that it’s huge of course, and still by no means final or exhaustive or authoritative.

In fact, it’s decidedly *not* the taxonomy of social media patterns we’re working on internally at Yahoo! Think of it as an open source, collaborative work in progress. The thumbnail image above links to a full-sized PDF you should feel free to grab to get a better look at the current state of play of this idea, and if you’d like the OPML file or any other format, just drop me a note and I’ll send it to you.

When I get a moment, I’ll drop by the BarCamp Block wiki and upload the file there in several formats too, at least until someone provides a better place for hosting this project.

Do pattern libraries really work?

· Patterns, Teamwork, User Experience

pattern-library-thumb.jpgI 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.