The “Hover Effect” for Mobile Buttons

A typical interface screen has many elements on it. Hover effects inform users what they can interact with by providing visual feedback on buttons.

A typical interface screen has many elements on it. Hover effects inform users what they can interact with by providing visual feedback on buttons. But there’s a problem — hover effects are for desktop apps, not mobile apps.

There are no mouse devices on mobile, so users don’t have the luxury of using hover effects. Using a hover effect on mobile apps causes buttons to stay stuck in the hovered state when tapped. This stickiness not only confuses users, but it frustrates them when they’re forced to double-tap buttons to initiate an action.


Removing the sticky hover effect isn’t enough. Mobile users need visual feedback because mistapping buttons is a common problem. The target sizes of mobile buttons are smaller than desktop ones and more challenging to hit. Not only that but sometimes their finger will hit a target with different surface area pressure that won’t always trigger the action. They need to know for sure if they’re tapping accurately.

The hover effect for mobile buttons is a ripple effect. A ripple effect provides the visual feedback users need when they tap a button. Users see a ripple animation on the button that assures them their finger hit the target accurately. If they don’t see a ripple effect, they know they mistapped the button.


A ripple animation is intuitive because it mimics the touching of water. When you throw a stone into a pond, there’s a ripple on the surface that allows you to see where it landed. The property of water provides visual feedback, just like a ripple effect.

It’s important to convert your desktop hover effects to mobile ripple effects. Doing so gives users certainty and assurance that they’re hitting their target after a tap attempt. It’s not quite like a hover effect, but it provides the same visual feedback users need when they interact with buttons.

Stop Misusing Toggle Switches

There are times to use toggle switches and times not to. When designers misuse them, it leads to confused and frustrated users.

There are times to use toggle switches and times not to. When designers misuse them, it leads to confused and frustrated users. If you want to know when you should use them, it’s important to understand the different types of toggle states and options.

Contextual States Vs. System States

It’s easy for designers to confuse toggle switches and toggle buttons because they both manage states, but there’s a fundamental difference. Toggle switches are for system states, and toggle buttons are for contextual ones. A contextual state only affects the current screen in focus, while a system state takes effect everywhere on the app.


Many apps misuse toggle switches by using them for contextual states. For example, a common mistake is to use switches for search filters. The filters only apply to the context of search, not to the entire system. Therefore, the proper selection controls to use are checkboxes, not switches.


Users expect switches to render an immediate effect when they toggle it on. However, the search filter settings don’t take effect until after users press the “save” button. If a screen requires users to press a button to apply an effect, switches are the wrong controls to use. A switch itself is the “button” that activates state. A separate button for the switch should not exist.

It’s typical to find switches in a settings screen of an app because that’s where users go to manage system states. But you can also use them for modes that affect the app. The example below shows switches for privacy mode and dark mode.


Binary Options Vs. Opposing Options

Switches are for binary options, not opposing options. A binary option represents a single state that is either on or off — or in other words, true or false. Opposing options are two separate states that are opposite but related to different user tasks.


Some apps make the mistake of using switches for opposing options. They place the option labels on opposite sides of the switch and use the direction of the thumb to indicate the state. This practice is a misuse of switches that confuses users because the visual cue isn’t clear. Not only that, but the switch has two different states without an off state as they would expect.

When you have opposing options, toggle buttons are the right control to use. In the example, “list view” and “map view” are the opposing options for users to toggle. A toggle button in this context works better than a switch because it groups the options and allows users to view them side-by-side. They’re also able to select each option directly and get clear visual feedback.

States Vs. Actions

Switches are for states and buttons are for actions. You should never use a switch in place of a button, or you’ll throw users off. When they see a call to action, they expect to interact with a button, not a switch.


The example shows an app using a toggle switch as a download button. This approach is a misuse of switches because downloading is a one-time action, not a persistent state. Turning the switch on downloads the content but ends after that. Turning the switch off doesn’t undownload it, which is misleading.

Three Conditions for Using Switches

Next time you’re considering a toggle switch on your app, check if the situation meets these three conditions. If it does, you’ll know for sure that a toggle switch is the correct control to use.

Use a toggle switch if you are:
1. Applying a system state, not a contextual one
2. Presenting binary options, not opposing ones
3. Activating a state, not performing an action