Design Patterns: Part 4

by Luke Wroblewski May 26, 2006

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

What do we mean by "design patterns"?

James Reffell I really like Bill’s discussion of the power of naming, both within the community of designers and when communicating with other stakeholders. Give a pattern a name – and the hard part is coming up with a name that evokes the spirit of the solution, rather than the details of the implementation – and then attach that name to one or more representative examples, and you can communicate a whole lot. I think it gets to the heart of design patterns – they’re a designer’s way of talking about design. We use words and pictures in combination to cut to the heart of a problem, and to illuminate a solution.

I’m intrigued by Luke’s question about using patterns versus trying something new, and I’d like to hear other folks’ take on it. My bias as a designer is almost always to borrow from existing patterns when available—both because it saves time, and because I feel the reuse of design patterns across products tends to help users orient themselves. Granted, sometimes the borrowed patterns end up in such different contexts they’re almost unrecognizable … but I don’t have an answer for how you know it’s the right time to go completely back to the drawing board. What are your thoughts?

Luke Wroblewski First of all, let me attempt to weave together what’s been said because I think it is a compelling story. Martijn started things off by referencing a design vocabulary that he built up through an awareness and study of design patterns. Jenifer pointed out this vocabulary is quite powerful when teaching people new to UI design how to think about problems and their solutions. Bill articulated the power of this vocabulary (and especially its nomenclature) when working on new problems and with different people.

So I think we are zeroing in on a key function of patterns: they help you to speak design.

Bill: “a way to recognize the solution when a similar problem context arises in the future”. For me this is how to “read” design. James: “both within the community of designers and when communicating with other stakeholders.” For me this is “speaking” design.

That said, I want to address James and Martijn’s points about using this “proven” design language vs. trying something new. In the past, I always used to reference the work of sculptors when discussing good Web design. “Just like a sculptor needs to know how marble chisels, breaks, and buffs in order to sculpt, a Web designer should know how CSS, HTML, and Javascript construct interfaces within a Web browser.” In other words, you need to be intimate with your medium. You need to know what it can and cannot do.

This, I believe, is the reason that we have both Web design patterns and Desktop application design patterns. They account for the specific context of their medium. Now as Jenifer mentioned, general, “Alexandrian” patterns should work across all mediums and I generally agree. Visual hierarchy, contrast, and more enable communication in posters, maps, Web sites, signage, and many other applications. But these generalist principles don’t cover the craft required to make them real. In the case of a sculptor making art in marble -it is hard to separate medium from message.

So we have the medium through with we are communicating and we have a language of design solutions. Now it becomes pretty easy to say: “I should do it this way because it is easier in my medium” or “I’ll simply use this pattern the way I did before.” Contrast this with the way David Lewis, who has controlled the design of nearly every Bang & Olufsen product since the 1980’s, works. ‘My role,’ he intones, ‘is to light a fire under people here, to give them impossible challenges.’

For me personally, there is something compelling and almost naturally innovative in forgetting what you know about your medium and your design vocabulary. After all, isn’t the point of learning the rules to know when and how to break them?

Jenifer Tidwell First, let me address the “use the proven design language” versus “try something new” question. Maybe it’s no different from other design fields – one learns the language, works in it until it becomes second nature, and eventually figures out how to transcend it to do truly original work. The thing is, your audience needs to be ready for original new ideas. I use patterns partly because they fulfill users’ expectations for layout and behavior; if we try to be so original that we go far beyond those expectations, we risk a total failure to communicate with our users. My employers wouldn’t like that very much, I think!

I agree with Luke about knowing one’s medium; I too think that designers ought to know CSS/HTML well (or Java Swing, or whatever technology they work with). I can see that there’s a place for technology-specific UI patterns. Bill’s group at Yahoo! has started filling that space nicely, in fact.

But I worry about the longevity of technology-specific patterns. On the Web, especially – and on mobile devices too – the technology is changing so fast. People keep coming up with new ways to implement dynamic and beautiful interfaces; look at how quickly Gmail and Google Maps raised the bar for web apps! If patterns are closely tied to current technology, won’t they become obsolete really quickly?

Then again, maybe that’s okay. There’s no reason why we can’t have both general patterns and tech-specific patterns out there, as long as they’re each clear about what they’re trying to do. As with any design task, maybe “designing” a pattern collection is a matter of knowing our audience and market niche, and communicating our purpose skillfully.

There is, I think, a deeper problem with tech-specific patterns that circles back to the question of originality. There are thousands of ways to design a Two-Panel Selector, or a Button Group, or a Center Stage – these very generic patterns leave lots of room for creativity. I’d hoped that by calling these out, we might better understand how to design unusual, original interfaces that are still usable. Specific patterns make me feel like I’m using a toolbox (which is not always bad, of course). The generic patterns give me a structure to work within, but enough creative space to imagine solutions beyond what I already know.

It's not over yet

More from Design Patterns in the coming weeks...