[author’s note: This is part one in a multi-part series. Based on material I developed with Christian Crumlish and Lucas Pettinati for a workshop we gave at the IA Summit in 2008 and 2009 and at Interactions 2009, I have expanded this information into a multi-day workshop and this series of articles. Once the series is complete it will be collected together as a white paper available as a PDF download.]
Houston we have a problem
At some point or another in a company’s lifecycle the interaction design team may find themselves seriously outnumbered.
They may be outnumbered by the corresponding number of developers and business folks. They may be outnumbered by the sheer amount of projects they have in their queue at any point. They may be outnumbered by the amount of projects and products that need to feel like they come from the same company. They may need to manage a pool of external consultants doing work for the company.
Whatever the issue, it’s usually at this point that someone on the team will think about an interaction design pattern library.
Chances are that the marketing department has already developed a Brand Style Guide with guidelines for how to use the logo and associated assets. This document generally is used to educate everyone in the company about proper brand usage and when work is outsourced to make sure outside consultants represent the brand appropriately. A pattern library solves very similar needs for the team for interactive experiences.
An interaction design pattern library can satisfy a host of needs related to efficiencies, consistency as expressed in user experience solutions and the ability to keep everyone on the same page—internal and external. Decisions around specific solutions and specific contexts represented in a pattern library can be as representative of the brand for the company as the logo. If the company products are interactive, then that interactive experience is the brand. A pattern library codifies the decisions around what will and will not be an acceptable solution in specific instances.
Additionally, when a team is outnumbered, a pattern library can inform developers and other cross-functional team members about settled design solutions so that the design team isn’t needed for every piece of a project. In these cases, the design team can act as director and provide feedback without having to do the heavy lifting of the design work.
A pattern library is also a good tool to have when there are a lot of designers as well. In this case, there are often a lot of different, disparate teams spread out across a company, across multiple offices and geographic locations. The pattern library becomes one of the tools in which all members can contribute to an agreed upon behavioral vocabulary for the company’s products.
The process by which the team defines the patterns in the library can rationalize multiple variants of a design, can refine outdated decisions and solutions and can help new employees come up to speed and get on the same page as the rest of the team in a quick and timely fashion.
When I was running the team responsible for the library at Yahoo!, we often had new employees reach out to us about various patterns. The library was a resource they studied upon joining the organization and was often referred to as they became accustomed to the way Yahoo! design worked.
So just what is an interaction design pattern?
When we developed the Yahoo! Pattern Library, we defined a pattern as:
an optimal solution to a common problem within a specific context
Patterns are used like building block or bricks. They are fundamental components of a user experience and describe interaction processes. They can be combined with other patterns as well as other pieces of interface and content to create an interactive user experience. They are technology and visually agnostic and we do not prescribe either of these. Interaction design patterns give guidance to a designer for how to solve a specific problem in a context in a way that has been shown to work over and over again.
A pattern also captures the situation, competing constraints and provides a canonical solution.
It is repeatable and is an archetype.
Up Next: Where did the idea of patterns come from? A brief history.
3 Comments
Comments are closed.