Last week, Christian and I had the pleasure of doing our Designing Social Interfaces day long workshop as part of Adaptive Path’s UXWeek. We had a great time and had a terrific group of people participating. Super engaged and collaborative, we had a lot of cool ideas created during the day. We also got a chance to play the game.

Here are slides:

And some pics from the day:

Last month I was one of the speakers at An Event Apart, Minneapolis. It was a fantastic experience and I highly recommend it. If it’s at all in your budget, get thee to An Event Apart. One of the best conferences I have ever been too. But then I am partial to very geeky things and appreciated the fact that this was geared towards designers and builders.

My talk was, surprisingly, not a Social Design talk, but rather a talk about Patterns – or more specifically Patterns, Components and Code, Oh My!

Here are my slides. The details of what I said are covered in my last post about the various libraries coming together as a holistic toolkit for the full team.

[Part 7 of a series on Patterns. Working with a Pattern Library.]

Patterns, Components, and Code, Oh My!

Ok, so now you have a pattern library. Now what? Ultimately, you need to be able to work with this content on a daily basis. The patterns, in and of themselves, give you the tools to understand the variety of interaction problems and various contexts of use. They also explore the considerations you need to address and resolve for your particular context. The patterns should give you all the rationale you need, with research and examples, to back up your decisions and know that you are starting with a usable solution.

By itself the pattern library informs, builds consensus, and captures shared knowledge BUT it’s hard to use in the real world when designing against a deadline. What a pattern does not do, is give you a working object that can be plugged into your sketches, wireframes, prototypes or final solutions. You need to be able to drop these solutions into your specific context for prototyping, for testing with users and for final builds.

With that in mind, you should consider the pattern library as just one part of a master toolkit. The pattern library should be the foundation for the entire toolkit which can be used by the entire team, including developers.

So what goes into the toolkit?

• a robust pattern library
• visual design guidelines and brand examples
• wireframe stencils of pattern instances or components
• foundational elements like grids
• related code components that map to the stencils and patterns

Each pattern in the library can be considered a hub around which all these other elements revolve.

The working objects that revolve around the pattern are specific instances of the pattern. Just like the sensitizing example in your pattern, which is an instance of the pattern in the wild, the code, component or stencil, css and specs are specific implementations of the pattern that can be used in your designs and even final builds. Ultimately, having this toolkit aids in adoption by the entire design and development team as it helps reduce inefficiencies and promotes reuse where appropriate.

In my experience, pattern adoption works best when engineers have reference and example code and can build solutions out of components just as the designers build experiences out of the patterns and stencil components.

Pattern + Stencil + Code = Very strong building block

So what do I mean by Component?

A component is a reusable, design system-specific chunk of a page.

Also known as modules, chunks, portlets, widgets, blocks, or other labels depending on the design context – are put together – like building blocks to create an entire page.

Components might have a specific application within a page grid, like a header or footer, and usually have prescriptive specifications for behaviors, formats, editorial, visual style, design rules and variable treatments needed for implementation. In the case of components that take advantage of ajax, they should include an interesting moments grid and behavioral guidelines.

In a pattern library, the component should be a reference design that follows agreed upon interactions and brand standards. For agencies, the component should be a generic, best case instance that can be skinned for various client needs.

Comparing Patterns and Components

Nathan Curtis, the expert on designing with components, has developed this matrix which defines patterns and components against a variety of points. He uses this to make a nice comparison between the two, which helps differentiate between them.

I don’t agree with his definition that a component has to be targeted to a specific location in the page. This may make sense as you are defining your grid system, i.e. Social tools widget always goes in the middle right column, etc. especially for a content CMS driven site. But the decision of placement as part of the definition of a component needs to be part of the design process and is related to the defining of your grid and module system and may not be appropriate at all for a web application or mobile experience.

In general, components may have location as part of their definition, but that location is dependent on the context of a SPECIFIC design system and not consistent to all design systems. You can develop components to use across projects, across clients or across different design systems for the greatest flexibility.

For designers, components might take the form of stencils that can be loaded as libraries for applications like Omnigraffle, InDesign, Axure, Fireworks etc. The Yahoo! pattern library team and others in the UX community, like Loren Baxter and Michael Angeles have released stencils that map to the patterns for many of these applications. Systems like EightShapes Unify bring a component based library set to InDesign.

All these solutions are used to aid in the design process and promote reuse while reducing the process of reinventing the wheel every time the designer sits down to work. Many designers I know have created their own personal, reusable set of stencils and design elements. The Toolkit formalizes this for use by an entire team. This is not unlike reusable code-libraries in use by development teams. It also means that designers can more easily share work and trade files with each other.

Code, code, code

Libraries like the YUI, jQuery, Silverlight and others are similar in concept to an interaction design pattern library. This is the part of The Toolkit that is most relevant to developers.

As seen by the rise of reusable AJAX libraries, code libraries are useful tools for developers to deal with standard and common interactions. Having a code snippet that maps to each pattern and component wherever possible means that teams can easily flesh out common interactions and rapidly prototype solutions.

Having a code library also means that your development team can focus on the more complex, unique interactions and features. They can spend time working on performance issues, database issues, crafting new code snippets to new patterns and other unique, one-off problems that often get short shrift because of the everyday, common features.

A few of the more common component libraries and frameworks include: Flex, Laszlo, Silverlight and 12 Ajax frameworks and toolkits: ExtJS, Dojo, YUI, Google Web Toolkit, Prototype/script.aculo.us, JQuery, MooTools, MochaUI, SproutCore, LivePipeUI,IT Mill, Backbase. (list compiled by Theresa Neil and Bill Scott)

Each of these has a set of components, of which many might map to a common pattern library set. The 30 components reviewed and covered by Bill Scott and Teresa Neil, span across all these different libraries.

The most usable toolkit for your company or team, might be a mix of off-the-shelf and custom components collected together with associated patterns, visual specs, css and stencils.

Interesting Moments Grids

The interesting moments grid was developed and promoted by Bill Scott while he was at Yahoo! It’s a great tool to develop collaboratively with your development team. He describes it as a storyboard or document that should accompany an interaction design specification which explains what happens to each element at key moments of use.

Defining each of these moments means that nothing is left to chance and every moment and behavior has been designed for the best outcome for users and for the best performance for the web application.

The Interesting Moments grid may be bound to code-based events or user initiated actions. Whatever the event of action, they all need to be discussed and defined. [drag and drop story board template | inline editing storyboard template ]

These documents are a great opportunity for interaction design and development to collaborate together. Both at prototype time and development time, the exploration of these actions and timings are as much about the user experience as an understanding of what’s happening with the code in terms of load time and what can be supported efficiently.

Figuring out Where to Start

For any organization, the success or failure of the pattern library and associated toolkit is going to be in how to approach the collection and codification of these tools in the most efficient, usable way possible.

For some teams, that means doing the research and writing work needed to create a pattern library from scratch. For others, it means pulling patterns out of existing specification documents. For another, it might mean developing a code library and then mapping the patterns back to it with rationale to support long term use of these solutions.

You can back out of a component library into patterns as long as you remember which level each belongs on. Patterns don’t dictate look, location or placement. They have a generic feel to them and that gives them an evergreen quality. The problem, solution, when to use and rationale for the decisions made in the solution should be valid regardless of media or technology. Your component on the other hand will dictate a lot of specific design, like placement of elements, timing of animations and ajax motions, specific labeling and even finished look and feel.

Small teams should spend their time collecting patterns and components from the large number of libraries available open source and spend their time documenting the deltas between them and their specific needs. This will cut down on a lot of work reinventing the wheel and will force the team to make decisions about what is specific and important to their organization.

Regardless of how you start, remember that the most thorough and usable toolkit, will have pieces that can be used by designers and developers day to day, backed up by the deeper foundational work of the patterns themselves.

Next up: How Visual Design Works in the Toolkit

[Part 6 of a series on Patterns. Organizing the pattern library for a design team.]

Organizing a pattern library is like organizing any other large body of content. You need to look at the content you have as well as the content to be developed and come up with a primary and a potentially a secondary mode of organization. When we developed the Yahoo! library we did some work in fleshing out a taxonomy and structure beforehand to help guide us in writing the initial patterns content. We did several batches of card sorting exercises after interviews with design staff to refine the corpus of potential pattern topics.

The structure you initially develop doesn’t necessarily need to be published, especially if it will be a while before it is all fleshed out. You might consider one way to organize at the beginning with another mode taking over as the content becomes more robust.

We found at Yahoo!, that alphabetical didn’t cut it because it stripped away the context of use. We later clustered the patterns based on topical groupings; social patterns, rich internet applications etc. This helps but it didn’t solve the cross context organizational issues.

Many patterns can fall into a variety of topics. Is Registration a form? Is Registration the start of an engagement process in social applications? Consider having both categories and tags so that patterns can be found across multiple facets. Finding methods might be a taxonomy browse, a search with faceted narrowing or clusters of links based on topics.

Organize based on a greater process.

Another option for organizing your patterns is to develop a framework in which they live based on user processes. For example, an onboarding process for new users might include a homepage or landing page pattern, a registration pattern, a welcome pattern, a new user engagement email pattern and then patterns for first time experience, 2nd visit and so on. This suite of patterns would be robust and would contain a lot of parts but ultimately would inform a whole cohesive process.

Robert Hoekman talks about designing in this way and calls them Frameworks. This is a good way to think about things in terms of their larger context and allows patterns to live in multiple contexts. It also maps to the user’s mental model of the larger problem they are trying to solve—here your user is the design team working with the pattern library.

Or they organize by action.

13 screen patterns from Bill Scott and Theresa Neil’s new book, Designing Rich Internet Applications. They use the screen patterns and 30 control patterns to create 100’s of options in the library.

Or Take the Alexandrian Approach

Approach the library as a language. Define the broadest concepts first. Sometimes these may called principles or best practices and are overarching concepts that can be applied to most topics across a variety of patterns or contexts.

Break it down to smaller components and mix and match as necessary.

Consider the human experience both in the organization of the library and in the patterns themselves. Ultimately it is about who will be using the library.

Whatever the philosophy, the pattern library needs to be organized in a way that all the designers using it can find what they need in an efficient manner.

Next up: Working With a Pattern Library Day to Day

[Part 5 of a series on Patterns. Developing a quality system.]

Once you have a collection of patterns they should be reviewed by the team or designated representatives.

A review process is good for catching missing issues or considerations as well as refining the problem statement and context of use.

Additionally, the review process helps socialize the pattern across a team and helps get everyone on the same page.

The review is a chance to bring everyone into consensus around the solution.

At Yahoo! we evolved this process several times over the years. The first attempt (documented in the article at Boxes and Arrows) ended up being too heavy and time consuming for the organization. Without a strong directive from management, it was too cumbersome to wrangle people from across the company to meet on a regular basis about something that was only tangentially required. Over time, we evolved to a loose group of senior and principle level designers, who had influence over their orgs and cared about this stuff, and conducted the review process through email notifications with a deadline. After the deadline passed the pattern librarian had the right to move forward with the feedback even if some people didn’t respond. We took a “no comment” as “ok to proceed” directive that everyone had agreed to. In this case, the patterns that were most applicable to a specific designer’s work or interests were the ones they became more heavily involved with and in the other cases they were ok to defer to other experts.

One person should be designated the pattern librarian. This role can rotate among team members to spread the work around. They will edit draft patterns – regardless of who writes them and will decide when a pattern is “done” enough for review.

The pattern librarian role is responsible for pushing the patterns out for review. There should be a designated time frame for reviewers to read the pattern and give feedback. The librarian will then synthesize and integrate the feedback and edit the pattern to reflect that. If the feedback is highly polarized or controversial, the librarian will send the pattern back to the author to gather more rationale to refute the feedback or to reconcile it with the solution.

The process of reviewing patterns can be done by individuals or in group discussions.

As previously mentioned, pattern blitzes can be an opportunity for a group of designers to come together and review patterns together. The pattern can be read aloud and the solution debated, challenged and/or recrafted. The original design author can share relevant research as the pattern is discussed.

The ultimate outcome of the pattern review process is twofold.

One – the group has consensus on the pattern as a working solution to a defined problem in context.

Two -the group agrees on a level of adherence desired going forward by all designers working with the organization.

The review process guarantees that the pattern is really a pattern, is the most archetypal solution to the problem as AGREED upon by the organization and isn’t a duplicate or a detailed specification.

Next up: Organizing a Pattern Library