No User Mistakes

Two columns are divided by a center line labeled "user action." An arrow strikes through the columns pointing from left to right, creating four quadrants. The left quadrants come before the user action, and are marked Preventable and Telegraph. The right quadrants come after the user action, and are marked Reversible and Feedback.

Come up with a better word for non-misclick mistakes. Misunderstanding. How did I not think of that? Thank you power thesaurus. Add something about destruction of information. No destruction, no undo.

Almost nothing is more frustrating than unintended actions. There are two types of mistaken user actions. The first is commonly referred to as a misclick. If the user never intended to perform an action, either because they accidentally pushed a button or because they missed the intended target of a button press, then the mistake is a misclick. The other type of mistake is when a user performed the action intentionally, but did not realize at the time the full ramifications of that action. If a user goes to delete a task and the project the task was in is also deleted, then the action isn't a misclick, it's just a mistake.

The best way to prevent mistakes is to always make interactions as simple as possible. Going to edit one entity, like deleting a task, should not cause side-effects, even in cases where the side-effect is necessary to prevent an invalid state. If a project can't exist without a task, the project system should be changed. It is very possible that the user intended to add a task immediately afterwards, but can't now, as the project is gone.

Not all user actions can be simplified, however, as some actions are naturally complex. Some applications will come with "smart features," where the program will attempt to help users when requested. A user might ask a task tracking application to assign tasks for the day based on importance and due date. The user isn't sure which tasks will be assigned, which is the point of doing it for them, but after the action is performed, the user might realize that they don't want these tasks assigned, and prefer that the action be reversed.

This example has lead us to our first tool for preventing mistaken user actions: making those actions reversible. Any and all actions that the software is capable of reversing, should be reversible by the user. In cases where the mechanism to reverse the action is obvious, like switching back to a tab that you've switched away from, the user can be left to their own devices. If the reversal takes any effort at all, however, then an explicit undo should be implemented. In the case of tasks being assigned for the user, a final step might ask if the user is happy with the assigned tasks, and remove them if not. Reversal of user action must be absolute. In order for users to feel comfortable performing actions, the reversal needs to have to lingering side effects, and any side effect found should be considered a bug by the developers and fixed.

Reversal of user action goes hand in hand with giving the user feedback on the effect of those actions. If the user is given the option to undo what they've done, but they aren't fully aware of what they've done, it's possible for the user to not realize the mistake until it's too late to trigger the reversal. Moving files from one folder to another often comes with no feedback, resulting in cases where I could accidentally drag a file from one place to another, and have no idea whether or not I had even performed a meaningful action. Slight, fleeting animations can be used to convey to the user that something has happened, which helps the user to realize a misclick has happened. If the user thinks that nothing of consequence was conducted, they might not realize the need to trigger a reversal, or they might avoid a reversal because they worry it will reverse some previous action instead.

Small animations to indicate that something happened are enough to indicate that a misclick happened, but do nothing to stop mistaken user actions. In addition to feedback that something happened, complex side-effects should be fully explained by feedback. In some cases, side effects are obvious enough that the slightest feedback is enough. If a checkbox pulses, indicating that it was clicked, it's very obvious what the side effect of that click was: The checkbox has been toggled. But in cases where the effect is more complex, the design of feedback might require more ingenuity.

Providing Feedback to the user and providing an option to reverse actions is the optimal strategy for user productivity. The vast majority of actions that the user performs, especially experienced users, will be informed and intentional. Feedback and reversibility allow users to operate as normal in those cases where a reversal is unnecessary, performing actions at will, safe in the knowledge that the undo button is there if needed. In cases where an action is made irreversible by some mechanism outside the applications control, then the best strategy is to prevent mistakes before they happen.

Preventing mistakes requires two things. First is to telegraph to the user exactly what will happen if they perform an action. This is equivalent to giving the user feedback on their actions, but before the user commits to the action. Feedback is often inherent in the interface without any effort put in by the developers. If an item disappears, it's been removed. Telegraphing effects, conversely, is often intentional on the developers part. Hover effects are a good example of telegraphing the effect of actions, which can be as simple as a descriptive popup label.

As long as telegraphing is obvious, it is usually sufficient to prevent mistaken user actions. Unlike feedback, where a user only learns what they've done after they've done it, an informed user who has decided they don't want to perform an action due to proper telegraphing will simply decide not to trigger that action. No amount of telegraphing will ever prevent misclicks, however, which must be prevented by making user actions more difficult. Remember that we're discussing irreversible user actions only. In these cases, the action should require steps that are difficult to perform unintentionally. Github requires that you type the name of a repository before deleting it, and you must perform this action in a big red danger zone. This proves that the action is both informed and intentional. Fuck that up.

And, of course, there's always the nuclear option. If an action can't be properly telegraphed, or is so dangerous it demands overt difficulty, there's always confirmation modals. A confirmation modal is the perfect blend of difficult to perform and telegraphing effect. A dialog requires that you click two buttons, spaced out by some distance, and they generally come with text explaining the effect of committing to such an action. Dialog boxes must not be overused, however, as users can become numb to its effect. All reversible actions should rely on reversal and feedback. If an action can be made more difficult without taking it all the way to a modal, it should be. If modals are reserved for only those cases where they are truly necessary, the user will be more amenable to its words of warning.

https://web.archive.org/web/20180728074014/http://www.androiddocs.com/design/patterns/confirming-acknowledging.html

#software #ux