Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

Design Patterns: An Evolutionary Step to Managing Complex Sites

by Jared M. Spool
on August 1, 2003

When your organization’s web site or intranet has hundreds of contributors, how
do you ensure that every page is high quality and extremely usable? Especially,
if these contributors have never designed a web page before?

This is a problem that many of our clients are facing and they’ve tried a
myriad of solutions, such as centralized approval processes, standardized templates,
and style guides, all without success. However, the one solution that really
excites us is now gaining a lot of attention — design patterns.

The Problem: Too Many Cooks

One of our clients is a consumer and small business equipment manufacturer
with 57,000 employees worldwide. Last year, more than 3,000 employees contributed
content to their corporate intranet. People from the all parts of the company,
such as the finance department, human resources, and manufacturing, were now
designing pages for others to use. However, many of these employees barely
use the web outside of work.

This is not an uncommon theme. Last week, we talked with a semiconductor manufacturing
company that has 300 people who regularly contribute to the corporate web site,
many with varying levels of design experience that ranged from "almost
none" to "slightly more than almost none". A month ago, we also
met with a financial services client who has over 250 contributors to their

While each of these organizations had a central web design/user experience
team, they were definitely outnumbered. In most cases, the team was only 2
or 3 individuals, saddled with the responsibility of keeping all of these pages
consistent, usable, and working. Each team admitted to us that they didn’t
even know how many pages they were responsible for and that there were hundreds
(if not thousands) of pages they’ve never personally seen. Yet, they were responsible
for every one of these pages.

Each team shared the same challenges: How do you get hundreds of new designers
on the same page? How do you help these folks start on the right foot, with
designs that are guaranteed to work and easy to implement? How do you encourage
them to leverage your experience and avoid mistakes that will create a disaster
and make more work for the understaffed and overwhelmed team?

No Help From the Tried-And-True Solutions

Even though these three organization’s teams had never ever met (and
didn’t really know the other existed), you’d swear that they’d been working
together. Each team had tried exactly the same solutions, unfortunately
with negligible results.

First, they each tried to set themselves up as a centralized clearinghouse
of design. Everyone submitting content to the web site had to first get approval
from one of the team members. Even though they didn’t want to end up as some
sort of police force, the shear volume of content being added to the site forced
them to be brisk and short with their co-workers. Inevitably, it all crashed
in around them as they just couldn’t keep up with the demands of the organization.

So, they tried a different approach — this time putting together templates
for the contributors. The idea was to provide a "safe starting point" for
each contributor, something that was guaranteed to produce a satisfactory design.
Each team quickly realized the problem behind this approach: each contributor’s
design problem was really different and needed different solutions. Maintaining
multiple templates quickly became cumbersome and the results of this lowest-common-denominator-style
of design were very unsatisfactory.

When the templates fell through, the next logical step that each team followed
was to assemble a style guide/guidelines document. The goal of the document
was simple — give the contributors some "rules to live by" that
are proven and tested. If the contributors would just follow the rules, they’d
produce excellent designs.

The contributors were happy to receive the style guide/guidelines document.
They wanted to know what the best practices are and how to implement them.
However, this solution didn’t work either. Many of the guidelines didn’t apply
to their particular situations. Or they were too broad or ambiguous to implement
effectively. The contributors quickly abandoned the guidelines, going back
to their old habits of just designing based on what they felt was right.

So, after all this, they were back to where they started — hundreds of contributors
doing their best, yet having virtually no guidance on creating good designs.
The chance that a page would accidentally turn out to be well designed
is slim, therefore most of the pages they were producing were less than satisfactory.

A New Hope — Design Patterns

The problem with templates and guidelines is that they only handle part of
the problem. Templates can get folks started, assuming that the design problem
is well understood (which it often isn’t) at the time the templates are created.
Guidelines work when they apply to the specific problem that the designer is
currently having (which they often don’t).

An experienced designer can use good judgment and work around the missing
information. But folks who haven’t created pages before need additional guidance.
This is where we think design patterns can be a huge help.

A design pattern is a document that describes a specific design problem, such
as presenting a login screen or creating a new account. A typical pattern describes
the problem, the chosen solution, the rationale behind that solution, related
patterns that the designer should be aware of, and other relevant details,
such as the results of usability testing.

While much has been written about patterns, the best web-related resource
we’ve found is "The Design of Sites" by Douglas K. Van Duyne, James
A. Landay, and Jason I. Hong. This book focuses primarily on web sites, offering
90 well thought out patterns for any team to start with. Their patterns include
myriad of commonly-faced design problems, from choosing page titles to implementing
a shopping cart.

The difference between patterns, templates, and guidelines is mostly in their
approach and attitude. Patterns embody desired behavior (such as "Here’s
a design that allows users to log in"), while templates describe a type
of page ("Here’s the login page") and guidelines describe
rules to follow ("Make sure labels are either to the left or above the
text entry field").

We’re excited because we think design patterns offer important advantages
over traditional templates and guideline approaches:

  • Design patterns describe individual design elements, whereas templates
    typically describe an entire page.
    Designers often need to mix-and-match
    design elements on a single page. To meet every potential requirement,
    the team would have to create a separate template for every possible combination
    of elements. Instead, a designer can choose the individual patterns they
    need for a particular page, much like a chef chooses individual appetizers,
    entrees, and desserts to make up a meal.
  • Guidelines are usually short, often not more than a paragraph
    or two, while patterns usually are multiple pages, going into much more
    Design patterns explain the problem, show the chosen solution,
    explain the rationale behind the choices, and talk about alternative approaches
    (often pointing to related patterns).
  • Within the body of the pattern description, the team can talk
    about why they favor that particular solution.
    This gives the
    individual contributor a strong recommendation with the underlying rationale,
    while allowing them the flexibility to deviate when the context of the
    design problems demands it.

The thing that excites us most about patterns is the message it sends from
the team to the contributors. Patterns suggest that the team trusts the contributor
to do the right thing, but that they might be missing essential design knowledge
that can really only come from experience.

By explaining the rationale behind choices and discussing alternative approaches,
patterns become an inclusive tool for the team, different from the
traditionally exclusive messages that come from centralized policing,
templates, and guideline techniques. This helps reduce the natural tendency
to create "Us vs. Them" contention between the user experience team
and the many contributors to the site.

Building the Library

Like templates and guidelines, patterns require serious effort to build up
the library. However, unlike their counterparts, both the team members and
contributors can distribute the work amongst themselves.

We recently heard from one client that they’re about to undertake a novel
approach to building their pattern library. Using the Van Duyne/Landay/Hong
patterns as a starting point, the team has asked 50 of their most advanced
contributors to produce one pattern a week, for a month. Each contributor has
also been asked to review two of their peers’ patterns each week. Their plan
is to produce and review approximately 200 new patterns, describing the most
critical elements of their current site.

Another client is borrowing from an old tradition to build up their library:
the pot-luck supper. They are holding regular meetings with their contributor
base, asking each person to bring one pattern to the meeting. Since patterns
often take only a few hours to complete, this is an easy assignment for each
individual, without overly burdening any one designer.

Because patterns are more like a standard engineering design specification
document than a rule book, it’s easier to get help to produce them. An organization
that has already produced hundreds of web pages needs only to document the
designs they’ve already implemented, thereby creating the initial set of patterns.
Over time, the team can then change the appropriate patterns to reflect new
thinking in the design direction, notifying all the contributors of the changes
as they occur.

The Natural Evolutionary Path

We’re excited with the promise of design patterns. They seem to be a natural
evolutionary path toward helping centralized design teams communicate with
the hundreds of contributors who are eagerly working on the web site. They
move away from the negative, disciplinary attitude that comes with templates
and guidelines, leading to a more collaborative way of working with all the
contributors. Plus, they come in an easy-to-use package that is straight-forward
to create. •

About the Author

Jared M. Spool is the founder of User Interface Engineering. He spends his time working with the research teams at the company and helps clients understand how to solve their design problems. You can follow Jared on Twitter at @jmspool.