Interaction design pattern

From Wikipedia, the free encyclopedia

This article may require cleanup to meet Wikipedia's quality standards.
Please discuss this issue on the talk page or replace this tag with a more specific message.
This article has been tagged since August 2006.

In interaction design/HCI, an interaction design (ID) pattern is a general repeatable solution to a commonly-occurring usability 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.

1 Common elements of an ID pattern
2 Uses of pattern
3 Example: UNDO
4 Aliases
5 History
6 Advantages over design guidelines
7 See also
8 Online Pattern collections
9 External links

[edit] 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.

[edit] Uses of pattern

Interaction design pattern, like many other design patterns, is used mainly for capturing experience, this can help us to:

Avoid repeating errors
Introduce existing interaction system to new designers.
Used for training and education.

As interaction design usually involve a large team with different disciplines. Interaction design pattern also aims at enhance communication between team members and even interdisciplinary communication.

[edit] 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.

[edit] 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).

[edit] 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 pattern (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 Design Patterns: Elements of Reusable Object-Oriented Software 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-centried system design. [Norman and Draper, 1986]. The classic 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.

[edit] Advantages over design guidelines

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. 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. Although they are still valuable at judging a bad design. Concrete guidelines like Macintosh Human Interface Guidelines are too tailored to a specific interface, while interface can be obsolete, concrete guidelines will be obsolete with the specific interface it tailor made for. 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 usual 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. Further a guidelines does not provide an explanation why a particular solution works. Guidelines and patterns are not conflicting, and can be used in conjunction a pattern embeds one or more guidelines into a specific description of a solution. Guidelines are therefore more useful for describing requirements where patterns are useful tools for those who need to translate requirements to specific software solutions.