It’s not a secret, that users very often, during the use of mobile devices, doing Tap on the wrong elements on the page. Sometimes these random clicks do not have any consequences, such as, users just miss the mark, do not hit the button or link, and sometimes the results of blunders can have dramatic consequences — when, for example, a reset of a completed form or leaving a page on which users would like to stay happen.

Such users’ mistakes can lead to refusals by using a mobile application or website, because users were accidentally sent back in the process of using, and they simply became too upset to continue (this mostly happens when it comes to data loss). This as well affects the business.

So what to do

The first step in handling random clicks on touch devices and not only — naturally avoid them. This is best done by carefully considering the various sizes and locations of important fields in your user interface.

And the second step is to develop a strategy for how you can gracefully handle random “clicks” when they occur.

There are different approaches to handling clicks, some of which are much more elegant (but often also technically more complex) than the others:

Do nothing — just don’t try to catch happenstance clicks and don’t process them. The disadvantage is obvious: random clicks are not factually processed, which means that some users will have unforeseen actions and failures in the script and process of use.

Demonstration of intent — require the User to explicitly show its intention. For example, confirming an action in the dialog box, click a button for a few times, long press or some similar extended interaction. The disadvantage of this approach is that all users perform more actions in the process of using the interface, regardless of or correct or accidental action.

Reversibility — the interface allows users to “undo” their action or “edit” its result after the fact. This allows unhappy users to return random “clicks” without burdening users with unreasoned or a more complex user interface. The main disadvantage of this approach is the technical (and logical) problems that may arise.

Ideally, of course, you should not think about what approach to choose but try to combine them all.

Do nothing

There is always the opportunity to do nothing and simply allow random clicks without options for seeking help. For actions with a high degree of seriousness, this is obviously an unacceptable approach due to the high cost of the UX, which it imposes on those unfortunate users who accidentally “push” an option or accidentally choose the wrong button at the moment of inattention.

It is important to understand that the cost of random clicks can be very high for certain actions, such as “Delete”, “Send” or “Pay”. Therefore, even if it happens to only a few users, the severity can be very high, and therefore potentially worth the extra effort required to handle these scenarios.

However, there are circumstances in which the approach of doing nothing can be quite useful. For example, if an action is non-critical (and especially if it should be repeated often), for example, archiving files or moving tasks to another list. In such cases, it may be more attractive to simply take action, rather than change UX or complicate the user interface.

Demonstration of intent

One of the methods to make sure that users really intend to perform the action they are calling is to ask them to confirm them. This is often easy to implement and, at least, it prevents truly random clicks, although they do not always catch a temporarily “absent user” who can continue to work in autopilot mode and, therefore, just simply agree with classic “confirm” dialog.

Asking users to confirm their actions is usually easy to implement, but unfortunately, it is also very intrusive to user experience and is called for everyone who performs the action, even the right one.

Confirmation requires additional efforts from all users, including those who intended to perform an action.

However, it can be a cheap way for rarely used actions.

By requiring users to demonstrate their intention, of course, one does not need to take the form of a classic dialogue overlay — there are variations that are aesthetically more elegant. For example, to confirm the action, the user may needs to press the button twice, or make a cell shift, or a swipe, or a long tap, and so on. Here the imagination is limited only by the convenience and competent of UX.


Allowing users to change their actions — is the final and, from the end user’s point of view, the ideal design strategy. However, this approach is technically difficult to implement and sometimes impossible to accomplish without delay action (for example, sending e-mail cannot be canceled, so the only way to suggest “cancel” is to postpone sending all e-mails).

For links and page navigation, we get “cancel” for free using the browser’s Back button (but make sure you follow the Back button’s expectations in this case). However, for such things as the presentation of the form and the action “Delete”, the “cancellation” is often much more difficult, both from a logical and technical point of view.

Nevertheless, it is possible to create several variants of this kind of “time machine”. For example, when deleting an item, you can not delete it immediately but place it in temporary storage, for example, the “Deleted” folder and save it in the database so that it can be restored if the user wants to cancel this deletion.

Yes, there are difficulties in implementing such an example. However, the costs associated with the implementation of this approach often create multiple positive experiences for end users. Now users no longer need to confirm their actions with a few clicks, pressing and holding, scrolling, or otherwise. Instead, users can perform the action in the fastest way and cancel it in case of an error.

But the reverse action to restore the object, of course, should be offered in an unobtrusive way so that it does not interfere or interrupt the flow.

For sure, there are scenarios where reverse actions are impossible. As a rule, they are associated with the transfer of data from your system to an external one (for example, sending e-mail, text message, etc.). Since your system cannot manipulate data in a third-party system, it is impossible to edit or undo the result of an action unless the third-party system explicitly offers these functions. In these scenarios, the action is irreversible after execution.

When an action is inherently irreversible, one of the ways to suggest “cancel” is to introduce a time delay between when the action is invoked by the user and when it is actually performed by the system — a transition period during which the action can be canceled.

It would be ideal to introduce a time delay as well as after completing the action to unobtrusively show in the interface the ability to perform this action immediately without delay if the user is sure of such a need.

“Undo action” is a very powerful approach because it avoids unnecessary steps or difficulties for the initial user interaction.

What to choose

Obviously, the trick is to choose the approach with the best return on investment. If the speed for performing certain actions by the user is important for you, then you need to use approaches that do not distract the user from the script. If the user needs to make informed and accurate decisions — then it is worth looking in the direction of approaches for clarifying intentions.

However, keep in mind also the number and frequency of actions taken. For actions that are performed many times and for solitary actions different approaches are needed. So for the first, it is worth choosing a smoother way, such as, deferred execution with the ability to cancel the action and for the second you can think of scenarios to clarify the intention. In other words, everything largely depends on how many times the user performs the action.

Consider all costs (for the user and your company) and savings (again, for the user and your company) and use these to decide which of the design approaches of handle accidental “Taps” or clicks to implement for your interface.

Inspired by Baymard

Source link—-138adf9c44c—4


Please enter your comment!
Please enter your name here