Interaction design patterns are design patterns applied in the context human-computer interaction, describing common designs for graphical user interfaces.

A design pattern is a formal way of documenting a solution to a common design problem. The idea was introduced by the architect Christopher Alexander for use in urban planning and building architecture and has been adapted for various other disciplines, including teaching and pedagogy, development organization and process, and software architecture and design.

Common elements

Though pattern descriptions vary somewhat, many pattern libraries include some common elements:

• Pattern Name: Choosing a clear and descriptive name helps people find the pattern and encourages clear communication between team members during design discussions.
• Pattern Description: Because short names like “one-window drilldown” are sometimes not sufficient to describe the pattern, a few additional lines of explanation (or a canonical screenshot) will help explain how the pattern works.
• Problem Statement: Written in user-centered language, this communicates what the user wants to achieve or what the challenge is to the end-user.
• Use When: “Context of use” is a critical component of the design pattern. This element helps people understand situations when the design pattern applies (and when it does not.)
• Solution: The solution should explain “how” to solve the problem, and may include prescriptive checklists, screenshots, or even short videos demonstrating the pattern in action.
• Rationale: Providing reasons “why” the pattern works will reinforce the solution, though time-pressed developers may prefer to ignore this explanation.
• Examples: Each example shows how the pattern has been successfully applied This is often accompanied by a screenshot and a short description.
• Comments: Including a place for team members to discuss the use of the pattern helps maintain an active resource and keeps the team engaged.

Optional elements

Pattern libraries can also include optional elements, depending on the needs of the team using them. These may include:

• Implementation Specifications: A style guide with detailed information about font sizes, pixel dimensions, colors, and wording for messages and labels can be helpful for developers.
• Usability Research: Any supporting research from usability tests or other user feedback should be captured. This can also include feedback from developers, customer service, or the sales team.
• Related Patterns: The pattern library may include similar patterns, or it may be organized into a hierarchy of parent and child patterns.
• Similar Approaches: Since there are likely to be many possible solutions to this problem, teams may want a place to capture similar alternatives.
• Source Code: If the code is modular enough to be reused, then it can be included in the library as well.