Our methodologies and deliverables for producing large-scale pattern and component libraries play a significant part in EightShapes‘ user experience design services. One might say that it’s a core strength of ours, or at least a leading practice area. So, I’m surprised it’s taken me this long to actually formally address the oft-asked question: “What’s the difference between a pattern library and a component library?” Boil that down a bit: “What’s the difference between a pattern and component?”

Why does this answer matter? While similar concepts in many ways, they serve fundamentally different roles within a user experience design workflow. Plus, because of pattern “hype” and universal recognition and acclaim for Yahoo’s Design Pattern Library, it’s created a more difficult challenge to communicate the unique value of component libraries to prospective clients (and reviewers of conference papers & workshops too).

What is a pattern?

From the IAWiki:

Patterns are optimal solutions to common problems. As common problems are tossed around a community and are resolved, common solutions often spontaneously emerge. Eventually, the best of these rise above the din and self-identify and become refined until they reach the status of a Design Pattern.

Peter Boersma offers a similar but distinct pattern definition:

Patterns are a general, repeatable solution to a commonly-occurring problem, proven effective or seen often enough to be considered worth following, and not formalized into a finished design that can be transformed directly into code.

Patterns can be utilized throughout a design life cycle to apply common solutions across a range of design systems, product experiences, and more. A few example patterns from the Yahoo library include:

• Autocomplete
• Navigation Tabs
• Rating an Object

What is a component?

A component consists of two or more elements that are combined to result in a structure that is standalone, reusable, design system-specific, and uniquely purposeful within a page view. Such components - also known as modules, chunks, portlets, widgets, blocks, or other labels depending on the design context - are always aggregated to compose a holistic page view. Each component evolves to have an understood context and application within the design system’s page grid as well as specifications for behaviors, formats, editorial, and more that’s specific to it’s instantiation in that system.

Components can prove to be a valuable asset during the design process. They can vastly improve the efficient, consistent, and scalable production and commonly understood documentation of experience assets across disciplines from information architects (wireframes) to visual designers (mockups) to design technologists (HTML/CSS/JS-based page templates). In fact, the most effective libraries foster collaboration and synchronization across these disciplines: IAs create wireframes by quickly dragging and dropping components that reflect (as much of) the visual language (as necessary) and foster correct HTML production, all from the same, shared taxonomy of component names/IDs.

Make no mistake - a component library doesn’t magically appear at the outset of designing a new system - that’s foolishness. Instead, it’s a reflection of a mature, existing design system across which many resources and disciplines participate in the much more streamlined, large-scale experience design process.

Example components include:

• Global navigation search box with autocomplete
• Tab, subtab, and tertiary tab navigation for primary content
• Customer product ratings

Components are organized in a library with a well defined namespace of IDs comprising attributes like components, categories, variations, and even examples. For example, the customer product ratings component may be named C19v1.CustomerRatings.Default, where C designates “Content” category, 19 is the component number, 1 is the variation number, and “CustomerRatings.Default” is it’s textual description.

The best component library I’ve ever seen or used is the publicly published Sun.com Component Library. Sun has even written publicly about the wireframing system EightShapes built to work in tandem with their code assets, terming the solution the “Right Tool for the Job“.

How are patterns and components the same?

Both patterns and components are:

• Reusable design solutions for specific problems

Ok, I said it, they are both reusable. In a sense, one could argue that a component is really an instantiation or very specific version of a pattern. This is probably the most important attribute that results in the confusion between the two concepts. Continuing on with the similarities:

• Described via attributes like Problem, Solution, Rationale, Use When
• Managed in a library
• Utilized during design projects by information architects, visual designers, design technologists (ie, HTML/CSS/JS jockeys), and other disciplines
• Authored and maintained via a (hopefully well) defined workflow
• Emergent from the design needs of a organization
• Influenced and enhanced based on user research

How are patterns and components different?

It may be evident already from the definitions above, but patterns and components are different. Key distinctions include:

There’s probably far more context and fewer words that could bring clarity to the distinction between patterns and components. But time has run out.

Phew, glad I got that off my chest.