Originally published: Jan 09, 2009
Invariably at the outset of planning a component library, stakeholders will query “Ah, yes, so we are building a pattern library?” Actually, no. Although the two concepts are strongly related, their differences warrant consideration to ensure you are building the type of library that’s right for you.
A pattern is a global solution to a common design problem, such that you could use the solution many times and never quite use it the same way twice.
For example, there’s no reason for a designer to not employ the common tenants of tabs (such as at least two tabs are required), video playback (that can be played or paused), or authentication (that, at a minimum, requires some form of username and password). Patterns are essential in interaction design, serving as a basis for designers to apply common, consistent conventions whether or not those solutions are actually catalogued in a library specific to an organization.
On the other hand, components are a reusable, design system-specific chunk of a page. Such components - also known as modules, chunks, portlets, widgets, blocks, or other labels depending on the design context - are aggregated to compose an entire page or view. Each component has a specific application within a page grid and may have prescriptive specifications for behaviors, formats, editorial, visual style, and variable treatments.
Patterns and components can be quite complementary and coexist within design solutions, even if (almost always) they are not the same thing.
Consider the home pages for two different experiences, fancast.com and comcast.net, both properties owned by Comcast Interactive Media and mapped together via navigation back and forth between sites. The two home pages could be broken down into components (represented by orange boxes), many of which are reused on other pages of each experience. Each home page also employs many patterns (identified by the red callouts).
Figure A: Component chunks (orange) and patterns (red) on the home pages of comcast.net (left) and fancast.com (right)
Are the components and patterns the same? Not at all. The two design solutions share no components whatsoever, existing within entirely different visual systems of grids, typography, layout, color, and navigation models. However, the two page designs share (at least) 5 patterns, including search, authentication, carousel, headlines, and tabs.
Figure B: Tabs used on cnn.com for mutually exclusive categories (e.g., Asia), content types (e.g., Video), and facets of a collection (e.g., Most Popular)
In every case, the design adheres to the fundamentals of a tab pattern, such as distinguishing the active tab from other tabs. However, the usage, page region, style, and design details differ considerably across each component.
Similarly, inconsistencies across many component designs can be reconciled into a pattern to establish a common baseline across teams and efforts.
For example, consider countless video players proliferating needlessly throughout the sections and contexts of a website: embedded in a product spotlight, a different player in a different spotlight, unique players in lightboxes & popups, new players for content from the training group, etc. Built by different teams at different times, the designs all play video amid UI controls with inconsistent behavior and appearance.
Teams can resolve differences via a pattern for basic facets like play/pause, scrubber, timing (current and overall duration), and volume. With a pattern in place, consistency increases but teams can still flexibly include (or omit) additional controls and features — video size, full screen view, rating, commenting, embedded code — for a specific component in the context of their solution.
Both patterns and components are reusable design solutions for specific problems. This reuse — and the consistency and cost-savings that result — is the key selling point of both patterns and components.
In addition, patterns and components can be:
Despite their similarities, components and patterns differ in important ways. At a high level, patterns are meant to serve as baselines open to interpretation and application by a designer; on the other hand components are quite specific to an established design and thus more prescriptive and fixed.
Additional distinctions include:
|Types||Could be a page chunk (log in module), flow (shopping from product to cart to checkout to receipt), behavior (e.g., autocomplete), or something else||Always a chunk of page or screen design|
|Specificity||Globally applicable across a range of contexts, even if elements are similar||Specific to one design system, including layout, color, type, and behaviors|
|Location||Up to the designer to appropriately apply principles and locate within a screen design||Targeted to specific location(s) within a page layout, based on approved usage|
|Style||Abstracted from any specific skin, and flexible to adapt to many visual treatments||Finished within one visual system, although variations may be defined|
|Editorial||Perhaps some basic editorial guidance||Specific data, formats, guideline, style/tone, and even defined feed|
|How It Works||Represents how a design should work, under preferred conditions (but may suggest how to cope with tradeoffs)||Represents how a design does work, inclusive of the tradeoffs and constraints established during the design process|
Since the two library types are different, then which one is right for you?
Patterns are ideal for teams that design many experiences, such as a team like Yahoo’s that designs a plethora of products each with a unique visual system but needing to adhere to a larger, common brand. Components have proven ideal for other teams, such as Sun Microsystem’s sun.com library that synthesizes a massive collection of pages, sections, teams, and content into a common, single design system and experience.
But, this may not be an either / or question, since depending on your circumstances, you may benefit from one or both types of libraries. In fact, one team built libraries for both patterns (e.g., Tabs) as well as components (e.g., tabbed product details, tabbed content module, tabbed search results, etc). Other teams have hedged their bets by embedding aspects of one approach into the guidelines and spirit of the other, most commonly via pattern-like guidelines incorporated into the more specific component definitions.
Consider a pattern library especially if your team has:
Consider a component library especially if your team has:
If you're thinking a pattern or component library can help your team be more efficient and create better designs, then you'll want to check out Nathan's full-day workshop: Standards, Reuse, Consistency, & Libraries at this year's User Interface 15 Conference in Boston on November 8-10, 2010. Nathan received rave reviews on a similar workshop he presented at the Web App Summit in 2009.
Nathan is giving a ful-day workshop at this year's User Interface Conference in Boston, MA. Learn about her session and the other 7 speakers at UICONF.com
As always, I want to hear your thoughts on this topic. Join the discussion about this week's topic on UIE's Brain Sparks blog.
Read related articles: