Interaction design pattern

In interaction design/HCI, an interaction design (ID) pattern is a general repeatable solution to a commonly-occurring usability or accessibility problem in interface design or interaction design.

See design pattern (disambiguation page) and pattern language (main article) to read about patterns as a domain-independent concept and their use in other domains.

Common elements of an ID pattern

An ID pattern usually consists of the following elements:

*Problem: Problems are related to the usage of the system and are relevant to the user or any other stakeholder that is interested in usability.
*Context: a situation (in terms of the tasks, the users and the context of use) giving rise to a usability problem. This section extends the plain problem-solutions dichotomy by describing situations in which the problems occur.
*Principle: a pattern is usually based on one or more ergonomic principles such as user guidance, or consistency, or error management.
*Solution: a proven solution to the problem. A solution describes only the core of the problem, and the designer has the freedom to implement it in many ways. Other patterns may be needed to solve sub problems.
*Why: How and why the pattern actually works, including an analysis of how it may affect certain attributes of usability. The rationale (why) should provide a reasonable argument for the specified impact on usability when the pattern is applied. The why should describe which usability aspects should have been improved or which other aspects might suffer.
*Examples: Each example shows how the pattern has been successfully applied in a real life system. This is often accompanied by a screenshot and a short description.

Optionally implementation specifications may be provided.

Uses of patterns

Interaction design patterns, like other design patterns, are used mainly for capturing experience, helping to::# Avoid repeating errors,:# Acquaint new designers with interaction systems, and:# Train and educate designers.

Interaction design usually involves a large team with different disciplines. Interaction design patterns aim to enhance both internal and external team communication.

Example: UNDO

One of the best known interaction design patterns is UNDO.

*Problem: Users may do actions they later want reversed.
*Context: Most applications where restoring the state after an erroneous action is relatively hard to do by hand e.g. when it requires several actions.
*Principle: Error Management
*Solution: Let the users reverse their last actions. Maintain a queue of executed commands and allow the user to undo at least the last couple of actions. Show the history of commands so that users know what they have done. A command is either a chosen function or a meaningful grouping of actions, for example typing a sentence or changing the printer settings. It is important that all commands can be undone. If a command has side effects that cannot be undone, warn the user before executing the command and do not queue it. In some cases, it can be meaningful to allow specific actions from the queue to be deleted. When one action is removed from the queue, all following actions need to be undone first and then redone.
*Why: Offering the possibility to always undo actions gives users a comforting feeling. They can explore, make mistakes and easily go some steps back, which facilitates learning the application's functionality. It also often eliminates the need for annoying warning messages since most actions will not be permanent.
*Examples: Adobe Photoshop, Office applications.

Aliases

As numerous people have worked on the patterns in Human Computer Interaction, the concept of an ID patterns is known under different names; e.g. interaction patterns, user interface (UI) patterns, usability pattern, web design patterns, and workflow patterns. These patterns share a lot of similarities and basically all provide solutions to usability problems in interaction and interface design. Some patterns are known under different names (or even the same name) in different pattern collections.

ID patterns can be described using PLML (Pattern Language Markup Language).

History

Patterns originated as an architectural concept by Christopher Alexander. Patterns and pattern languages for describing patterns are ways to describe best practices, explain good designs, and capture experience in a way that it is possible for others to reuse this experience.

Design patterns in computer science are extensively used by software engineers for the actual design process as well as for communicating a design to others. Software patterns first became popular with the object-oriented book. Since then a pattern community has emerged that specifies patterns for all sorts of problem domains: architectural styles, object oriented frameworks, domain models of businesses and interaction patterns.

The Christopher Alexander's approach to interaction design was first suggested in Norman and Draper's seminal book on user-centred system design. [Norman and Draper, 1986] . The Apple Computer's Macintosh Human Interface Guidelines had also quotes Christopher Alexander's works in its recommended reading.

The first substantial set of interaction design patterns was the Common Ground pattern collection, developed by Jenifer Tidwell. Many other collections and languages followed, such as Martijn van Welie's Interaction Design Patterns. Several books have recently been published about Web and UI design patterns, including:
* "A Pattern Approach to Interaction Design," by Jan Borchers
* "A Pattern Language for Web Usability," by Ian Graham
* "The Design of Sites: Patterns, Principles, and Processes for Crafting a Customer-Centered Web Experience," by Douglas K. van Duyne, James A. Landay, and Jason I. Hong
* "Designing Interfaces: Patterns for Effective Interaction Design," by Jenifer Tidwell

In early 2006, Yahoo! began releasing their internal pattern catalog to the public for general use, feedback, and commentary. This may indicate a new direction for ID patterns development.

Advantages over design guidelines

Guidelines are generally more useful for describing requirements whereas patterns are useful tools for those who need to translate requirements to specific software solutions. Some people consider design guidelines as an instance of interaction design pattern as they are also common approach of capturing experience in interaction design. However, interaction design patterns usually have the following advantages over design guidelines:

1. Abstract guidelines like the Eight Golden Rules of Interface Design by Shneiderman do not suggest how to solve a problem like many interaction design pattern, and cannot be used for interdisciplinary communication. Furthermore, guidelines do not provide an explanation as to why a particular solution works.

2. Concrete guidelines like Macintosh Human Interface Guidelines are too tailored to a "specific" interface, and therefore are not as effective when applied to other interfaces (especially non-Macintosh interfaces).

3. Other problems with guidelines are that they tend to be too numerous which makes it difficult for designers to apply the right guidelines. Also guidelines assume an absolute validity while usually they can only be applied in a particular context. A result of that is also that guidelines often tend to conflict just because they lack describing a context.

Guidelines and patterns are not necessarily conflicting, and both can be used in conjunction to identify the problem and then create a valid solution.

ee also

* Design patterns
* Gameplay
* Information architecture
* Interaction
* Interactivity
* Interface design
* Usability
* User-centered design

References

External links

* [http://designinginterfaces.com Designing Interfaces]
* [http://www.cs.kent.ac.uk/people/staff/saf/patterns/plml.html PLML: Pattern Language Markup Language]
* [http://www.visi.com/~snowfall/InteractionPatterns.html The Interaction Design Patterns Page maintained by Tom Erickson]
* [http://www.hcipatterns.org hcipatterns.org]