Design Patterns: An Evolutionary Step to Managing Complex Sites

by Jared M. Spool

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 site.

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 detail. 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.

Published here on August 1, 2003.