About the author

Eelke Folmer

Picture of Eelke Folmer.
Eelke Folmer is an assistant Professor at the University of Nevada in Reno. Previously he worked as a postdoctoral fellow in the Software Engineering / Games Group at the University of Alberta. He received a PhD degree from the University of Groningen where he worked on the European Union funded Software Architecture for Usability (STATUS) project.   His research interests revolve a...   
Become a member of the Interaction Design Foundation
Eelke Folmer
Eelke Folmer is a member of The Interaction Design Foundation

Eelke Folmer

Bio Publications

Upcoming Courses

go to course
UI Design Patterns for Successful Software
88% booked. Starts in 7 days
go to course
Affordances: Designing Intuitive User Interfaces
87% booked. Starts in 8 days

Featured chapter

Marc Hassenzahl explains the fascinating concept of User Experience and Experience Design. Commentaries by Don Norman, Eric Reiss, Mark Blythe, and Whitney Hess

User Experience and Experience Design !


Our Latest Books

The Social Design of Technical Systems: Building technologies for communities. 2nd Edition
by Brian Whitworth and Adnan Ahmad
start reading
Gamification at Work: Designing Engaging Business Software
by Janaki Mythily Kumar and Mario Herger
start reading
The Social Design of Technical Systems: Building technologies for communities
by Brian Whitworth and Adnan Ahmad
start reading
The Encyclopedia of Human-Computer Interaction, 2nd Ed.
by Mads Soegaard and Rikke Friis Dam
start reading

Interaction Design Patterns

by Eelke Folmer. How to cite in your report.

An interaction design (ID) pattern is a general repeatable solution to a commonly-occurring usability problem in interface design or interaction design. An ID pattern usually consists of the following elements:

As numerous people have worked on the patterns in Human Computer Interaction in recent years, the concept of an ID patterns is known under different names; e.g. interaction patterns, user interface (UI) patterns, usability patterns, 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.

History of interaction design patterns

Patterns originated as an architectural concept by Christopher Alexander (1977). 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. In addition to the patterns Alexander defined a set of rules e.g. a pattern language in which patterns could be meaningfully combined. 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 design. 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:

Example interaction design pattern: Multi-level Undo


Undo in Microsoft Word using a visualization of the command queue


Martijn van Welie http://www.welie.com/patterns/gui/undo.html


Users do actions they later want reverse because they realized they made a mistake or because they changed their mind.

Use when

You are designing a desktop or web-based application where users can manage information or create new artifacts. Typically, such systems include editors, financial systems, graphical drawing packages, or development environments. Such systems deal mostly with their own data and produce only few non-reversible side-effects, like sending of an email within an email application. Undo is not suitable for systems where the majority of actions is not reversible, for example, workflow management systems or transaction systems in general.

Both novice and expert users may want to reverse their actions, either because of mistakes or changes in intention. Expert users may want to use the history of their actions for more specific manipulation of the data in the application. For example, in a graphical modeling application, users may want to undo work on some specific object while keeping later work done on other objects.


Error Management (Safety) (Norman, 1988)


Maintain a list of user actions and allow users to reverse selected actions.

Each 'action' the user does is recorded and added to a list. This list then becomes the 'history of user actions' and users can reverse actions from the last done action to the first one recorded. This is also called a Linear Multi-level Undo.

Interacting with the history

There are two variations on how to show the history of actions to the users. First there is the standard 'office-like' way where the 'Edit' menu contains both 'Undo' and 'Redo' functions with their keyboard shortcuts. Often there is also a widget in the toolbar that can show the last items in the history. By dragging the selection in the list, actions can be undone. A second variant is to work with primarily with the history list itself and moving a slider or scrollbar to move back in history and undo actions. Photoshop uses such a variant.

Displaying actions

Actions in the history are usually displayed using a text label such as 'Create circle', 'Typing',' New contact'. Such labels only name the function and not the object the functions work on. In some applications it may be better to include the object and the parameters as well, for example 'Change-color Circle12 to Red'.

Granularity of actions

When designing Undo it is important to determine the desired granularity of actions. For example, it is usually not desired to record each key press in a text editor as an action. Instead, typing a word is used as a unit of action. Designers need to determine what unit of action is appropriate in the application.

Non-reversible actions

Although most actions in the application may be reversible, it is very likely that some actions will not be reversible. For example, printing, saving, doing a payment, or downloading an object. For actions that are non-reversible and 'negative' of nature (like paying or destroying something), need to show the user a Warning Message and not add the action to the history.

Selective undo

In some cases, it can be meaningful to allow single actions from the history to be deleted. This is the case when a certain 'episode' of work must be deleted or undone while keeping work that has been done later on. Selective undo is conceptually much more difficult than linear undo since there is a notion of 'dependency between actions' that determines the consequences of undoing a particular action. For example, if a 'create circle' action is undone at some point in the history, subsequent actions in the history working on that object loose their meaning and must be deleted. There are many semantic issues with selective undo, see Berlage (1994) for more information on selective undo.

Object-based Undo

Object-based Undo can sometimes be considered as an alternative to Selective Undo. With Object-based Undo, each object has its own action history. Upon selecting the object, the users can undo actions done on the object. Naturally, this requires the application to have a clear concept of an 'object' and is therefore not applicable for bitmap editors. See Zhou and Imamiya (1997) for more on Object-based Undo.

Multi-user undo

If the application is a multi-user application and uses undo, the application must distinguish between local actions and global actions. That leads to multiple histories and requires special semantics for what happens when undoing actions. See Abowd and Dix (1992) and Sun (2000) and Ressel and Gunzenhouser (1999) for more on multi-user undo issues.


Offering the possibility to always undo actions gives users a comforting feeling. It helps the users feel that they are in control of the interaction rather than the other way around. 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


As in all MS Office applications, in Word 2000 the users can see the history of their actions and undo one or more of them. The actions are briefly described and the users can select a range of actions to be undone. After selecting undo, users can even redo the actions.

In Photoshop a selective undo is also possible. By moving the slider, users can do the normal multi-level undo but they can also drag an action into the trashcan and thereby do a selective undo. Operations that depended on that action are automatically deleted as well of they are not relevant anymore.


Most implementations of multi-level undo are based on the Command (Gamma et al 1995) pattern. When using the Command pattern, most functionality is encapsulated in Command objects rather than in other controlling classes. The idea is to have a base class that defines a method to "do" a command, and another method to "undo" a command. Then, for each command, you derive from the command base class and fill in the code for the do and undo methods. The "do" method is expected to store any information needed to "undo" the command. For example, the command to delete an item would remember the content of the item being deleted.


Join our community and advance:




Join our community!

User-contributed notes

Give us your opinion! Do you have any comments/additions
that you would like other visitors to see?

comment You (your email) say: Oct 26th, 2014
Oct 26
Add a thoughtful commentary or note to this page ! 

will be spam-protected
How many?
= e.g. "6"
User ExperienceBy submitting you agree to the Site Terms


 what's this?

Abowd, Gregory D. and Dix, Alan J. (1992): Giving Undo Attention. In Interacting with Computers, 4 (3) pp. 317-342.

Alexander, Christopher, Ishikawa, Sara and Silverstein, Murray (1977): A Pattern Language. Oxford University Press

Berlage, Thomas (1994): A Selective Undo Mechanism for Graphical User Interfaces Based on Command Objects. In ACM Transactions on Computer-Human Interaction, 1 (3) pp. 269-294. Available online

Borchers, Jan O. (2001): A Pattern Approach to Interaction Design. John Wiley and Sons

Gamma, Erich, Helm, Richard, Johnson, Ralph and Vlissides, John (1995): Design Patterns: Elements of reusable object-oriented software. Addison-Wesley Publishing

Graham, Ian (2003): A Pattern Language for Web Usability. Pearson Education

Norman, Donald A. (1988): The Design of Everyday Things. New York, Doubleday

Ressel, Matthias and Gunzenhauser, Rul (1999): Reducing the Problems of Group Undo. In: Proceedings of the International ACM SIGGROUP Conference on Supporting Group Work 1999 November 14-17, 1999, Phoenix, Arizona, USA. pp. 131-139. Available online

Sun, Chengzheng (2000): Undo Any Operation at Any Time in Group Editors. In: Kellogg, Wendy A. and Whittaker, Steve (eds.) Proceedings of the 2000 ACM conference on Computer supported cooperative work 2000, Philadelphia, Pennsylvania, United States. pp. 191-200. Available online

Tidwell, Jenifer (2005): Designing Interfaces: Patterns for Effective Interaction Design. O'Reilly and Associates

van Duyne, Douglas K., Landay, James A. and Hong, Jason I. (2002): The Design of Sites: Patterns, Principles, and Processes for Crafting a Customer-Centered Web Experience. Addison-Wesley Publishing

Zhou, Chunbo and Imamiya, Atsumi (1997): Object-based Linear Undo model, Proceedings of the Proceedings of the IFIP TC13 International Conference on Human-Computer Interaction. In: Howard, Steve, Hammond, Judith H. and Lindgaard, Gitte (eds.) Proceedings of INTERACT 97 - IFIP TC13 Sixth International Conference on Human-Computer Interaction July 14-18, 1997, Sydney, Australia. pp. 252-259.