A Cheatsheet of the Most Common Interaction Patterns — DELETE

Building on my post about Conversational Design for Digital interfaces, I tried to standardize the most common interaction (and conversation) patterns prevalent in apps today. This series will explore the most common interaction patterns we see in most apps today. However, this is not meant to be a comprehensive list. There may be many more patterns not captured here, but most follow a slight variation of the ones listed in the series.

You can read the rest of the articles:

1. CREATE Interaction Patterns
2. READ Interaction Patterns
3. UPDATE Interaction Patterns
4. DELETE Interaction Pattern (this one)

DETELE — Interaction Pattern

As the name suggests, DELETE operations remove an Object or record from a database. Because of its destructive nature, it is critical that the consequences of taking this action be clear for the user.

Deleting an Object

In most delete operations, the record is deleted or destroyed in the database after the action is taken, and the user may not be able to retrieve it. Suppose the application does not offer an “Undo” action or does not have a place where deleted items are stored. In that case, it is critical to show a Confirmation Dialog, especially if it is a “high-stakes” type of environment or task. It also helps to do the following:

• Using red or a color evokes a strong emotional response in a given culture.
• Using an icon that is closely associated with “danger.”
• Inverting the usual placement of the confirmation button prevents the user from carelessly acting without adequately thinking about the consequences.

Remember that you are confirming a user’s intent. So it makes sense to call the most attention to the destructive action.

Deleting an Object using simple gestures

Most modern applications offer the ability to delete objects quickly with one gesture, especially for applications where the user may do repetitive tasks. If you follow this pattern, you must provide

In this case, we use motion to convey the deletion of the Object. Ideally, you should not rely on motion or animations alone to communicate something to the user, as this benefits only sighted users. In some cases, what happened may also not be evident regardless of the user’s abilities. Aim to accompany the animation with a Feedback message to be safe. However, in cases where the action is highly repetitive, you may use animations alone if:

• The application has a repository of deleted Objects where the user can find deleted Objects for some time.
• You communicate a feedback message via Screen Readers.

Deleting an Object in a details page

In some cases, the user may be performing a delete operation in a context that affects how the Object is presented in the application. Detail pages are an excellent example of this. Suppose the user navigates to an Object’s Details page where they can perform actions associated with that Object. In those cases, when the user deletes the Object, the user should also be navigated to the parent page, and a Feedback Message should be displayed for context (see example below).

You can read the rest of the articles:

1. CREATE Interaction Patterns
2. READ Interaction Patterns
3. UPDATE Interaction Patterns
4. Delete Interaction Pattern (this one)

This concludes the CRUD series. Remember that this is not meant to be a comprehensive list of patterns, but I noticed that most modern patterns follow a slight variation of one or most of the ones listed in these series.

PS. If you have any feedback or if I forgot to include any patterns, let me know so we can add them.

Let’s help each other build better experiences. For everyone.

Stay safe,

Oscar.