If you spend any amount of time poring over pattern libraries, you’ll quickly see they fall into a fairly common
[cough] pattern. They’re organized into an array of sensibly-named categories, like “icons”, “buttons”, or “tables”. Within each category, you’ll find a host of individual interface modules, with a standalone example of the design pattern, often accompanied with a bit of code. Since the usability of a pattern library often determines how successful (or not) that library will be in an organization, it follows that design patterns—and the code that powers them—should always be as organized, as findable, as accessible as possible.
Recently, a programmer/consultant named Brian Marick wrote up a few thoughts about design patterns. Now, he’s talking about patterns as they apply to software engineering—but I think what he’s saying is relevant to the web, too. I’ll quote his short Twitter thread here:
Everyone talks about how all design is about tradeoffs. People urge designers to think about tradeoffs, not jump straight to design. What people don’t talk about is where you get the tradeoffs to think about.
In [the] original Alexandrian formulation, patterns were all about “resolving forces” - an idea close to tradeoffs. In the popularization of software design patterns, forces were notably left out - as were contraindications.
I’m feeling like patterns should be revived, done better this time, focusing on them as a source of tradeoff knowledge.
I’d never really connected those threads before, but Marick is right: our contemporary understanding of design patterns is quite different from the original definition. Namely, that idea of compromise—of “resolving forces”—isn’t something I see in most discussions about design patterns on the web.
“Design pattern,” as a term, is something we’ve inherited from Christopher Alexander’s book A Pattern Language, which suggests that when a person designs a building, she relies on a kind of design language to do so. That language is fairly formal, and has a vocabulary built out of patterns, which are solutions to specific problems. Alexander’s book attempts to catalog what he believes are the most commonly-used patterns—for example, “
STREET WINDOWS”, “
THICK WALLS”, and “
WINDOW PLACE”—and explores how they might best be used.
This probably feels pretty familiar to any web designers or developers who might be reading this. On the web, we think of patterns as reusable interface components. Let’s say you’ve got to display an image next to its caption. To do so, you’ll create a simple pattern that lets you, well, display an image next to its caption. But the pattern’s value comes out of how reusable it is; you’ve created a design element that allows you to display image/caption pairs on every page of your website. Now, the content contained in each instance of that pattern would be different, but the structure and layout would be consistent: the image would always be sized just so; the caption always set in the same type; and the position of the two elements would always be uniform. And with your pattern designed, you’d likely add it to your pattern library or style guide, ensuring it’s accessible to other designers and developers.
But Marick’s tweets reminded me there’s a subtle but significant gap between our definition of “design pattern,” and where the concept started. As an example, here’s Christopher Alexander describing a pattern:
The most impressionistic and intuitive way to describe the need for the entrance room is to say that the time of arriving, or leaving, seems to swell with respect to the minutes which precede and follow it, and that in order to be congruent with the importance of the moment, the space too must follow suit and swell with respect to the immediate inside and the immediate outside of the building.
We shall see now that there are a tremendous number of miniscule forces which all come together to support this general intuition. …At [one] time it seemed important to emphasize the separate and individual patterns defined by these forces. However, at the present writing it seems clear that these original patterns are, in fact, all faces of the one larger and more comprehensive entity, which we call
THE ENTRANCE ROOM.
While the patterns defined in the book are fairly common, even archetypal—“
MAIN ENTRANCE”; “
FARMHOUSE KITCHEN”; “
BATHING ROOM”; and so on—the actual execution of a pattern was meant to be shaped by outside forces: the light available to the room might determine the placement of a window; the size of an entrance, by how frequently that room might be used; and so on. In other words, a pattern never exists in isolation. It is always defined by, and shaped by, its environment.
In our discussions around patterns on the web, and in our pattern libraries, I’d love to see much, much more of this. Whether it’s in our pattern libraries or in public, design patterns are often displayed in a kind of gallery format, presenting the reader with a list of generic module names: “tabs,” “navigation,” “grids,” and so on. And while this makes it easy to browse different design patterns, I’d love to see more discussion of the benefits (or drawbacks) that would lead to choosing one pattern or another. Does your pattern library say how and when a pattern is meant to be used? If the design of your image/caption pattern was shaped outside forces—by the kind of content inside it, by business requirements—are those considerations, those tradeoffs documented in your pattern library?
In other words, I’d love to see us discuss and document patterns in the context of how and why they were made. Because for me, that reasoning is what enables a collection of patterns to mature into a fully-realized design system. Organizations like Salesforce, Vox Media, and Airbnb are wonderful examples of this in action, as they’ve foregrounded the design principles that inform, well, the design of their patterns. And Lisa Maria Martin’s article for 24 Ways provides a timely, eloquent reminder that our patterns aren’t just part of one one brand’s visual system, but part of a larger design fabric.
We need more of this, I think. Our pattern libraries are still considered to be deliverables for front-end design and development teams—and rightly so! But there’s an opportunity to make them more than collections of interface snippets. We should keep defining how patterns look, how they’re built, and how to integrate them into our websites—but we don’t have to stop there. We can also better describe the compromises we make—the forces we resolve—when we design (and use) our patterns.