Understanding design patterns in your everyday work

by Ryan Singer (@rjs)

This article was originally published to Feltpresence.com in March 2012.

The concept of design ”patterns” is widely misunderstood. I want to give you a solid understanding of what patterns really are and how they reflect what designers already do every day.

What is the misunderstanding? First, in the 90s the idea of “design patterns” became popular in the software world, and mentioning the term brings specific, enshrined programming techniques to mind (eg. Strategy Pattern, Decorator Pattern). Later some UI people tried to create pattern libraries, but they focused on collecting examples and formalizing their presentation instead of explaining what a pattern really is and how it plays into daily design work.

A pattern is a simple thing, and you already use patterns every day when you design. You’re thinking about a problem and all of a sudden a solution pops into your head. “Aha. I could put those things in a list.” “I’ll float that link on the right side of the header.” “I’ll write that in a bold headline, and put the details in a smaller line underneath.”

A pattern doesn’t need to have a name, and it doesn’t have to come from a book. A pattern is some design trick that is lying around in your head, and when the right problem rises up in front of your nose, the pattern pops into your mind as a solution. You know the feeling, right?

Here are a few off-hand examples from my own mental library:

You can probably fill a few pages with your own favorite patterns. They are as simple as this.

But there is also more to the story. Why is a certain pattern appropriate in this situation and not in that situation? What dictates a pattern’s fitness to a given problem? To answer that, think of each pattern as more than a possible solution in your bag of tricks. Each pattern is also a definition of a problem.

Let me show you what I mean. Here’s a pattern I use all the time:

In practice it often looks like these:

That’s what the pattern looks like and how I think of it. The ”problem” side of the pattern is made up of these forces:

• The user is in a process where they have uncommitted state (eg. they composed a comment on a blog but haven’t posted it yet.)
• Most users who reach this state will want to commit what they did and move forward.
• Some users, fewer than the others, will reach this state and decide they do not want to commit and move forward.
• Users who do not want to continue aren’t satisfied with getting up and walking away from the screen. They want to clear out the uncommitted state or do something else in the app.
• Users on the majority forward-moving path would be negatively impacted if they clicked on the wrong action.

These forces are the context that I had in my mind when I first used this design. Later, when I encountered those same set of forces again, I recalled the solution that I came up with earlier and how well it fit. A large button with a smaller adjacent link came to mind, it again fit the bill, and again reinforced the pattern.

This happens over and over as we design. Patterns entrench themselves in our mental library through this process of encountering a situation, designing a solution, recognizing the same situation again, and recalling and applying the earlier solution.

The forces don’t have to be explicit. I never wrote them down before this post. But being aware of the forces makes it possible to critically analyze why you are making a specific design choice and how well that choice fits with the situation.

Taking patterns off the pedestal and noticing them in your everyday work is empowering. You don’t have to think about whether a pattern is a ”real” pattern or not. A pattern doesn’t need to be written in a collection or formalized to be part of your design toolbox. Then once you start to notice your own common patterns, you can begin to analyze the forces behind them. When you are aware of the forces that motivate your decisions, you can be conscious of whether you are designing by habit (“this is what I always do here…”) or whether you are actually applying the most fitting solution to the problem at hand.

References:

1. On the interplay of forces and design solutions: Notes on the Synthesis of Form (Amazon)
2. My talk on the design process as the resolution of conflicting forces: http://vimeo.com/10875362
3. Christopher Alexander’s original book on patterns: A Pattern Language (Amazon)