Patterns are formal descriptions of best practices within a given design domain. They capture common solutions to design tensions (usually called "forces" in the pattern literature).
The idea of patterns actually started in the field of architecture (as in physical buildings). The first book (in the 1970s) on patterns and pattern languages (collections of related patterns) was Christopher Alexander's A Pattern Language. The “Alexandrian” format for documenting patterns is still very popular today. Patterns were introduced to the field of commercial software engineering in the mid-1990s by the publication of Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
In recent years, patterns have taken hold in the field of Human-Computer Interaction (HCI). A very good introduction to UI patterns is Common Ground: A Pattern Language for Human-Computer Interface Design (http://www.mit.edu/~jtidwell/interaction_patterns.html) by Jennifer Tidwell at MIT. There is a growing body of literature on the topic, as well as a number of peer-reviewed UI pattern websites, such as—
- UI Patterns and Techniques (http://time-tripper.com/uipatterns/index.php)
- Interaction Design Patterns (http://www.welie.com/patterns/)
UI design patterns do not separate system behavior from “look”. The traditional approach to “Information Architecture” views visual identity as decoration for functional behaviors. A pattern, on the other hand, describes an entire solution to a task (e.g. choose an account from a list), including the way it should look and feel. A pattern can optionally describe the best way to code the solution (Coding best practices can also be written as separate patterns cross-referenced to the behavioral and/or visual appearance patterns.). In other words, UI architecture standards and style guide can ultimately be combined in the same document in an easy to understand format.
Patterns:
- Are observed through either formal user research or experience.
- Are typically written in a structured format
- Are reusable artifacts (i.e. prevent “reinventing the wheel”).
- Exist at different levels of abstraction (e.g., structural patterns vs. behavioral patterns).
- Undergo continuous improvement.
- Communicate design and best practices.
- Can be used together to solve a larger problem.