Design Patterns: Part 2

by Luke Wroblewski May 24, 2006

Part two of Design Patterns: a conversation about defining and sharing user interface design languages (be sure to check out part one first).

What do we mean by "design patterns"?

Luke Wroblewski Bill and Martijn both did a great job articulating the differences between general design patterns (principles) and prescriptive design solutions (guidelines). So I won’t chime in with yet another set of definitions. Besides, what’s interesting to me is the context and implications of the origins and usage of both types of patterns.

As an interface design consultant, I’ve spent over ten years researching the business goals and user needs of different domains so I could provide the right design solutions for my clients. From hospital operations to professional educator training to radar traffic monitoring, the only constant across my work has been my medium: Web-based applications. As I put together interface design solutions for these different industries, underlying patterns began to emerge at many levels -all the way from application frameworks down to icon semiotics. It turned out that despite different contexts, users, and businesses, many basic requirements for Web applications were the same.

When I began to recognize this consistency between requirements, I naturally migrated to some degree of consistency in my solutions. After all, what was thought through, tested, and worked in a similar context had a higher likelihood of success than something unproven and unique. Though I never formally defined these solutions as patterns they did become my “design vocabulary” (as defined by Martijn).

This vocabulary was built up through my process of breaking design problems down into their basic components, recognizing similarities and differences between them, and mapping them to a particular solution. Some would call this a deconstructive approach.

My experiences within large design organizations, however, have been a bit different. When many different design teams work on a single large product of a suite of products, consistency is important. Everyone needs to know the same “design language”. In other words, when faced with the same design problem, different designers should apply the same solution. In this context, patterns are useful when they are prescriptive solutions.

Because large design organizations tend to move through a lot of products quickly, assembling patterns through deconstruction is often not an option. Few people have enough breadth of responsibility to see the same problem played out in different contexts and there isn’t time for principles to “naturally” emerge. Instead, a particular solution may be generated or embraced as a pattern simply because people need an answer fast. This constructive approach creates guidelines that many organizations “require” designers to apply. How well it actually works is open for debate.

In terms of implications, something I always struggle with is to what degree does my “design vocabulary” influence my designs. At this point in my career, I have a long list of valid solutions for many requirements. So of course it is easier for me to apply one of these solutions then to take the time to create something new. (As a consultant, it’s financially better for me to as well.) But am I doing my client and the users of their product a disservice by falling back on proven solutions? Isn’t there merit to wiping the table of known solutions clean and building from the ground up? Isn’t that what “capital D” design is?

Bob Baxley recently told me a story from a design management book he read. A an architect found out the building he had designed required budget cuts that that would cost him a large number of square feet thereby making his current design unusable. Frantic, the architect’s clients flew out and the team spent all day fitting the previous design’s features into the reduced space. After a grueling day, the team was celebrating their accomplishment, when the architects took the plans they designed and ripped them to shreds. Shocked, the clients asked: “Why did you do that?” The architect responded: “Now that we know we can do it, how do we want to do it?”

Jenifer Tidwell My “ten words or less” definition of patterns is that they describe best practices in design. So do guidelines and other approaches, of course. But the pattern form is unique — patterns span the very abstract and the very concrete, while residing somewhere between those extremes. They describe common semi-abstract design elements; they explain why those elements work in terms of abstract principles, and they’re illustrated by a variety of concrete visual examples that can span the range of the pattern. That breadth is a lot more useful to a thoughtful practitioner than ordinary lists of principles or guidelines.

I think one of the most valuable aspects of UI patterns is their independence of technologies and trends. Patterns that work well in Web apps should also work in desktop apps, for the same reasons; patterns that worked for paper forms 30 years ago should still work in online forms now. The principles don't change, after all. This is why I don’t include code in my UI patterns — code unnecessarily ties them to one technology. Why not go for “timeless” if we can?

Recently, I’ve begun to suspect that some UI patterns might capture cognitive schemas: abstract mental constructs that people use to make sense out of a novel UI. Two-Panel Selector is one of these. Everyone recognizes them; everyone has a mental model for how to use them, even when they come in many different guises. I’d like to explore the pattern/schema concept further, and maybe do some experiments to test its validity. If it’s true, then we can say with conviction that patterns really do help users understand UIs!

But patterns also have a subjective component: they must improve the user experience. They might do that by aiding understanding, or maybe by evoking senses of playfulness, rich interaction, stability, or other emotional responses. This is one of the few ways in which I adhere strongly to Alexander’s original vision. (I’m not that dogmatic otherwise.) To me, a pattern isn’t worth writing down unless it clearly benefits the user’s state of mind; and designers who use patterns should carefully judge whether a pattern works to do so in a given context.

Getting away from the theoretical stuff for a moment, I want to talk a bit about why I started writing patterns and what I’ve used them for. I’ve used them as design vocabulary, as brainstorming tools, and in other ways described by the participants in this conversation. Not mentioned so far: pedagogy. Teaching, in other words.

A lot of people who build user-facing software haven’t been taught graphic design or interaction design. These two domains have built up canons of principles and exemplary works that show the application of those principles, but if the people creating UIs haven’t “done their time” studying such, then their own solutions are not as rich or well-informed. They suffer from a lack of perspective: “Microsoft did it this way, therefore so should I, down to the exact detail.” Or, “Apple just did this incredibly cool thing in the newest OS X, and we’ve got to find a way to use that idea in our product!” I’ve heard developers say things like this. Copying isn’t so bad, but they didn’t know how to break down the good idea in question into that which was essential and that which was not (like exact phrasing or layout). And they often didn’t recognize that the essential core of the idea was the same as one they’d just seen in a different application.

So — knowing that there are no shortcuts around actual experience and training — how do you give people enough perspective and knowledge to design reasonable interfaces from the get-go? I found the pattern form to work exceedingly well. It’s not preachy, it doesn’t come across as a “style guide,” and it’s eye-opening for people who haven’t yet thought about UI design at a higher level of abstraction. It ties theory to practice, without over-prescribing design to the point of being reductive. When done right, patterns give less-experienced designers much of what they need to know: what the best design practices are, how to spot them, why they work, and how to use them while allowing for local creativity and variation.

The Conversation Continues...

Check out part three of Design Patterns