Over there on on the User Experience group on LinkedIn, there is a loong thread cataloguing existing UX/UI design pattern repositories. Recently, a few folks have been asking, “so what’s up with these UX design patterns, anyways?”
Given that I’ve had a lot of experience with design patterns, both in software architecture and, more extensively, with UX/UI design patterns in my work on Infragistics’ free UX/UI design pattern explorer and design tool, Quince, I thought I’d offer some food for thought. I put most of the following as a comment there, but I figured making it more top-level in this post would help. Hope it helps you out. Feel free to ask questions/comment if you want! 
Design Patterns have a very well-defined, long-lived meaning. As Steven H (another commenter) noted, we inherited the formal denotation first from physical-world architecture via Christopher Alexander and, indirectly, through software architecture. They are not just a new word for an old thing…
Using a pattern does not mean you are copying someone’s work. Design patterns are not algorithms, templates, or rote repeatable solutions. Design patterns rely on context heavily, both to validate that they are applicable and to inform the concrete design. That’s why it’s important to understand not just the problem that they solve and not just the solution (and certainly not to simply copy examples of it), but also the context and rationale behind them.
Like many things, design patterns are a tool, and they are not always applicable or even helpful. To effectively leverage them, you first need to understand what they are and when they are applicable.
In the end, design patterns are there, and you use them whether or not you acknowledge them formally. Every time you use a textbox in a UI, you’re using a pattern. Every time you use a drop down, you’re using a pattern. When you put a search box in the top right area of your app, you’re using a pattern. The list goes on and on and on (check out Quince for more examples, or any of the other design pattern repositories).
Where it can help to formally recognize them is to make you a more informed and cognizant designer, so you can better choose when to leverage which patterns. They can also help to form a common vocabulary to enhance team communication, and they can be building blocks for any particular design language. Personally, I think they are indispensable in a designers’ toolkit. At the very least, they make you more aware of and able to articulate the rationale behind your designs, which is crucial in arriving at the best possible design.
