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.

This is a second draft. You can find the first draft here: [[20200819175536]].

Add something about destruction of information. No destruction, no undo. Add something about information, specifically? Nah

Almost nothing is more frustrating in app design than an action which is easy to perform accidentally but difficult to fix. 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 knocked a button entirely by mistake or because they missed the intended target of a button press, then the mistake is a misclick. The other type of mistake is a misunderstanding—a user performed the action intentionally, but did not realize the full ramifications of that action. If our project manager, Betty, removes Fred from her task tracking app, only to find out that this has also immediately deleted all of Fred's assigned tasks, then the action isn't a misclick, it's a misunderstanding.

The best way to prevent misunderstandings is to make interactions as simple as possible. Editing one entity, like deleting an employee, should not cause side-effects, even in cases where the side-effect is necessary to prevent an invalid state. If a task can't exist without assignment, the task system should be changed to allow for unassigned tasks. It is very possible that the user intended to reassign those tasks immediately afterwards, but can't now, as the tasks have been preemptively deleted.

Not all user actions can be simplified, however, as some actions are intended to perform complex side-effects on the users behalf. These features are usually prefixed with the adjective "smart," as in, Smart Assign: automatically assign tasks to employees. Betty might request that tasks automatically be reassigned to new employees once Fred's been canned. Betty isn't sure exactly which tasks will be assigned to whom, and after the action is performed, she might realize that she doesn't like the outcome. When this happens, the action must be reversible.

Actions that the software is capable of reversing, should be reversible. 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 assignment, and reverse them if not. Please note, reversal of actions must be absolute. In order for users to feel comfortable performing actions, the reversal needs to have no lingering side effects, and any side effect found should be considered a bug.

Not a fan of this paragraph ->

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 aren't fully aware of what they've done, the reversal is useless. Consequences should be limited to the current page. If tasks are deleted without any physical presence on the screen, the user will have no way to notice that the tasks have disappeared. In addition, as often as possible, these consequences should trigger some amount of motion or color change. Slight, fleeting animations can helpful to inform the user that something has happened, which allows the user to realize when a misclick has occurred. Even if the user is aware that they accidentally clicked their mouse, they might not realize that a clickable element was actually triggered. If they don't recall exactly what was on the screen before the interaction, they might think that nothing has changed.

Subtle animations are enough to convey that something has happened, but do little to help alleviate misunderstandings. If the user clicked a button without realizing exactly what the button did, informing them that the button was clicked does not help. In order to correct misunderstandings, complex side-effects should be fully explained by feedback. In some cases, side effects are obvious enough that the custom feedback is unnecessary. If a checkbox is ticked, it is very obvious what the side effect of that click was: The checkbox has been ticked. But in cases where the effect is more complex, the design of feedback might require more effort and ingenuity.

Custom feedback is expensive to produce and often unnecessary, but in some special cases, it can be vital to the user experience. If a project managing application is filled to the brim with smart features, most of which revolve around automatically assigning tasks, building a fully animated gantt chart might be worth the investment. If a user is able to perform an action—say, adjusting a slider which affects the importance of due dates in assignment—and is given constant, up to date feedback on to whom each task is being assigned, complete with animations to help drive come the effect, and is given the tools to reverse that action if needed, the user will not fear the complex and unpredictable action.

<- run on sentence which is poorly constructed, spread it out.

Feedback and the option to reverse mistaken actions is the optimal strategy for mitigating mistakes. The vast majority of actions that the user performs, especially experienced users, will be informed and intentional. Feedback and reversibility mitigate mistakes without slowing the user down. In fact, a consistent option to reverse actions can allow the user to move faster, as the user will be able to perform actions quicker if they are covered against accidents. In cases where an action is truly irreversible, like sending an email, then the application should strive to prevent mistakes before they happen.

Preventing user mistakes requires two things. First is to telegraph to the user exactly what will happen if they were to perform the action. This is equivalent to giving the user feedback on their actions, only the side-effects are conveyed before the action is performed. Unlike feedback, telegraphing is almost always custom built. If a user removes an item, and the item disappears, feedback has been achieved. Telegraphing effects does not come so easily. Hover effects are a good example of telegraphing the effect of actions, which can be as simple as a descriptive popup label, or as complex as temporarily updating the screen to represent the effect of a click.

The shift from custom telegraph effects to hover feels abrupt. Try to tie hover effects into the idea that telegraphing is custom built.

Telegraphing consequences may require more effort than feedback, but is usually sufficient to prevent misunderstandings entirely on its own. Unlike feedback, which must be combined with reversal to mitigate misunderstandings, telegraphing will prevent the misunderstanding from ever occurring. No amount of telegraphing will ever prevent misclicks, however, which can only be avoided by making user actions more difficult to perform. If the action triggers irreversible consequences, misclicks can only be prevented by making the action difficult to perform. Purchasing an item in Destiny—a multiplayer video game—is not an action that the player is allowed to reverse, but it at least requires that the player hold the purchase button down for a short time.

Most mechanisms that make an action more difficult to perform also, unfortunately, cause accessibility problems for disabled users. For this reason, the most common way to prevent accidental actions is to present a confirmation modal. Confirmation modals prompt the user to confirm that they really want to perform an action by clicking a second "yes, really" button. In this way, a confirmation modal combines prevention of misclicks with telegraphing of effects. The model doesn't only prevent accidents, but is often filled with text explaining the consequences of such an action. Confirmation modals must not be overused, however, as users can become numb to its presence, and confirm almost out of habit. If an action can be made more difficult without taking it all the way to a modal, it should be. Nonetheless, in cases where side-effects are difficult to explain without dialog, or the consequences of performing an irreversible action are dire enough to justify momentarily impeding the users productivity, a confirmation modal is an option.

And, of course, there's also the nuclear option: require the user to type their action before committing to it. Github requires that you type the name of a repository before deleting it, and this action must be performed in a big red danger zone, proving that the action is both informed and intentional. The user probably won't misclick an entire repository name, and there's no chance of misunderstanding which repository they were deleting. The method is also novel enough that the user will not skim passed its warnings, as often happens with confirmation modals.

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

#software #ux