Pattern-based design seems to be getting a lot of interest in the UI community lately, and is being taken fairly seriously by some high profile players like yahoo.
Just to refresh, design patterns are general repeatable solutions to commonly occurring problems. There’s a putative measure of objectivity or optimality attributed to design patterns, distinguishing them (in theory at least) from what are often called “best practices,” which tend to be derived through convention.
To sort things out in my own head, I came up with this visual scheme for slotting patterns into the interaction designer’s toolbox. Obviously, this is not the only way to slice things up:
I had a bit of trouble deciding what should go in the top-right box. By quality attribute, I mean desirable traits like learnability, modularity, explorability–the “ilities” of design, which I think are both fairly abstract and context-dependent or subjective. These are sometimes called soft goals or non-functional requirements in systems design.
Back to design patterns. We’ve commented here before that we tend to be cautious about methodologies that are borrowed from other disciplines; we need to constantly ask ourselves, how will this help us improve our work?
Design patterns in software engineering are meant to be used in a deductive, rationalistic fashion. So you have this general problem or requirement, X, design pattern Y solves X, therefore use Y. Now, when I reflect on my own process and I’ve got reason to believe that I’m not alone here, I find that it’s more organic than that, more inductive than deductive, more bottom-up than top-down.
Obviously, there’s a balance to be achieved. When a project is in the initial bootstrap phase and I’m trying to make the jump from abstract requirements to a concrete design solution, I’ll often perform a sort of breadth-first search. During this phase, I’ve found design patterns to be helpful, allowing me to quickly frame up the design problem in concrete terms.
I think that pattern-based design has the potential to move interaction design forward, but we need to sort out how this will jive with established methodology that works in the other direction (e.g. scenario-based or iterative design), and also how to balance the value of standards and conventions with improvisation and innovation.