Please note: This site's design is only visible in a graphical browser that supports Web standards, but its content is accessible to any browser or Internet device. To see this site as it was designed please upgrade to a Web standards compliant browser.
Signal vs. Noise

Our book:
Defensive Design for the Web: How To Improve Error Messages, Help, Forms, and Other Crisis Points
Available Now ($16.99)

Most Popular (last 15 days)
Looking for old posts?
37signals Mailing List

Subscribe to our free newsletter and receive updates on 37signals' latest projects, research, announcements, and more (about one email per month).

37signals Services
XML version (full posts)
Get Firefox!

An Introduction to Using Patterns in Web Design

05 Oct 2004 by Ryan Singer

The biggest challenge for web designers is the unthinkably huge number of possible ways to solve any given problem. We usually don’t think of this because we have our habits and traditions to fall back on, but there are literally billions of possible pixel combinations for each page we make.

There is a better way to manage this vast complexity than by making big decisions up front and hoping for the best. To make better sites — sites that are functional, beautiful, and “usable” — we have to break our design problems up into small independent chunks based on the real issues within our requirements. Christopher Alexander, who came up with this stuff, calls these chunks patterns.

Read the rest, including a fully worked-out example…

21 comments so far (Post a Comment)

06 Oct 2004 | indi said...

This does make a lot of sense. An interesting example where this chunky thinking would work is at the Zen Garden. In this case thoughtfully used CSS allows the entire page to be reformatted. If the pieces are conceptualized as chunks it would geatly aid laying out a new design and accompanying style sheet.

06 Oct 2004 | Justin French said...

Nice to see such a process spelled out in black and white, even if it pretty much verbatim for the way I already work :)

06 Oct 2004 | Gilbert Lee said...

Well done, Ryan. I especially like this:

Start by making a list of all the specific bits... this includes what info the page should get across, what actions it should support, important attitudes of the users...Do not prioritize, group, or categorize. If you start by grouping and organizing you'll just end up with your original habits and preferences in the end.

The only thing I don't think is quite as effective is the font size change. The font size differences in your final example are so subtle I'm not sure the visual hierarchy is shown effectively. How about a bigger font size difference? or a different font color for the name? or a background for the entire section?

06 Oct 2004 | timfm said...

Good stuff Ryan. You might want to add: The Design of Sites: Patterns, Principles, and Processes for Crafting a Customer-Centered Web Experience to your references. An excellent book of interaction patterns in the tradition of Alexander by the peeps at UCal's Group for User Interface Research.

06 Oct 2004 | mindful_learner said...

There have been quite a few attempts by the HCI/Usability community to leverage Alexander's ideas on patterns. The main problem has usually been that they mimic the form of his work without understanding the substance, i.e. the theoretical framework behind the idea of patterns. Alexander's work comes from a deep, mathematical analysis of patterns in nature - the notion that elegance, beauty and harmony in the enviroment are an objective element of nature rather than just a subjective choice. As such, for PHYSICAL structures, we can uncover meaningful objective patterns that people will tend to find pleasing. Now, there is no certainty that these ideas extend to interfaces - really the underlying theory needs to be expanded to see if it fits with this type of design before we can then look to uncover patterns. Otherwise, 'patterns' just becomes another word for 'design principle' or heuristics or 'copy what others have done'. This isn't wrong as such, just not really adding much value.

That said, I liked the article and as others have commented it is nice to see a design process/framework nicely mapped out.


06 Oct 2004 | Steven Huey said...


I was at the Building of Basecamp last month in Chicago, and think a breakdown of your process like this article describes would be an excellent addition to the interface design portion of the presentation.

06 Oct 2004 | Zelnox said...

I'm glad more and more people are looking at design patterns. ^_^

06 Oct 2004 | Paperhead said...

I must be missing something here, because Step Three sure quacks like an assumption.

06 Oct 2004 | Jason L. said...

I'm interested in hearing how folks decide whether to use a button or a link when associated with a user action. For example, the sample here has "Edit Company" as a button while "Change My Search Preferrences" is a link, but presumably both would take the user to a new page.

06 Oct 2004 | Andrew said...

We typically use a link in our web apps when the result is clearly "going somewhere else" and a button when the result is clearly "remaining in the same place" (although the content might have changed slightly).

And of course there are times in the same apps when this general rule obviously doesn't work, so we ignore it.

07 Oct 2004 | ~bc said...

Fascinating. I look forward to more papers.

07 Oct 2004 | John S. Rhodes said...

On a broader topic I wrote about an article about systems design about 3 years ago. Here's the summary:

"The purpose of this paper is to briefly review and discuss three books related to systems design. The first book is Design Paradigms: Case Histories of Error and Judgment in Engineering (Petroski, 1994), the second book is The Mythical Man-Month, Anniversary Edition: Essays on Software Engineering (Brooks, 1995), and the third book is Notes on the Synthesis of Form (Alexander, 1964). In this paper, an emphasis is placed on describing the core ideas of the books. Brief discussions of structure, context, failure, and usability engineering are included to highlight several themes found throughout the trio of books."

Investigations in Systems Design: Structure, Context, Failure and Usability

Ryan is much more specific in his article and certainly hits on more web-related ideas. However, you might want to consider looking at my article to get a broader perspective on system design. Mileage will certainly vary!

07 Oct 2004 | Stefan Seiz said...

Rally interresting. Well done. I do agree on the fontsize difference however, they don't make sense.

And another kind of unrelated comment: always use "" when making up email addresses. is there exactly for that reason. Just imagine the poor folks at

07 Oct 2004 | Don Schenck said...

I put Ryan's suggestions to work immediately on the application in front of me. Thanks.

07 Oct 2004 | Dougal Campbell said...

Consider this a manual trackback. Patterns in Web Design, from geek ramblings.

"37signals has yet another excellent article out. This one is called An Introduction to Using Patterns in Web Design. Some of it might seem obvious, or even instinctive, if you've been doing programming and/or web design for a while. But it's a really good breakdown of a design process."

08 Oct 2004 | Jonathan Blake said...

The final output has a password ******** displayed. Frankly, I fail to see the point.

08 Oct 2004 | Allan Rojas said...

amazing article Ryan, i've been looking for a useful pattern guide for quite a while... i'd love to see a second part, focusing on using patterns to take the graphic sketch into XHTML/CSS...

best regards.

08 Oct 2004 | p8 said...

I'm not convinced about the use for UI patterns. I have read the Gang of four book so I'm familiar with programming design patterns. I find them very useful because having names for these abstract concepts helps communicating, using and seeing these patterns.
To quote Christoper Alexander "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."

So are the 12 'bits' your patterns? Should they be named "Company info pattern" and "Other users on this account pattern"? Is that really useful?
Can they be categorized in more abstract name?

I understand the patterns in Interaction Design but do we need to spend time documenting them?
I mean most people know what "advanced search" (a 'UI Pattern') is but ask anyone what a Abstract Factory (a programming design pattern) is and you'll see a lot of blank expressions.

At css-discuss they are having trouble defining CssDesignPatterns.

08 Oct 2004 | Peter Flaschner said...

In essense, what's being discussed is the core of any design project:

1 understand your client's message (described in your article by brainstorming and listing the elements),

2 interpret that message (prioritize those elements), and

3 communicate it to the intended audience in the most effective way.

The article is a helpful reminder not to jump to the design stage, but to let the content inform the design. But I'm failing to see what's so revolutionary here. Creating the hierarchy of messages, be it branding vs copy vs feature A vs feature B, etc is the root of good design. Is it just that this is a systemized approach?

09 Oct 2004 | anonymous said...

interresting for beginners

09 Oct 2004 | anonymous said...

true, good people reads it !
everybody should already know that and work this way

Comments on this post are closed

Back to Top ^