We're having a discussion in the UX department here at work as to whether or not hover states are necessary to a UI. We're kind of divided. Here are the two arguments:

Against (started the discussion):

I have personally had a predisposition to not have hover states…to me, it adds visual noise without really any benefit except in very limited circumstances. Coming from the mobile world, there is no such thing as a rollover state, and I have never missed this or wished that is available for basic items. PC software did not used to use rollovers, but I was just testing it out and I see that they are now used heavily. But I looked up some Mac YouTube Lion videos and they do not appear to use hover states.

For (first response):

The short answer is, yes, we need to have hover states on every button in our interface. And I typically extend that to anything clickable (list-box items, links (although that comes for free), and any other custom elements like whiteboard nodes or table cells). I would bristle at the idea as well, and will typically be forcing hover states to be added if they aren't already.

It’s funny because this is just something that is so standard now that it’s never questioned. Most research I can dig up have to do with what the right hover treatment rather than testing whether hover should be used. You’re right that it wasn't used in the past but that was more a UI technology deficiency. It is certainly possible users just expect it and so the technique has become a de facto requirement. Moreover, not having hover tends to come across as antiquated. For those reasons, coupled with the fact that I don’t think hover states have any negative effect on usability, is why I’d say we should always use hover.

I’m not sure I quite see the visual noise component. I always push designers to make hovers very subtle (like 60-80% of whatever the selected state is). When they are done correctly they provide visual feedback to the user that the control does something. It also helps the interface communicate with the user—it’s as if it tells the user that the application is listening.

Here's my addition to the conversation (I am pro hover states):

I think there is an inherent necessity for hover states on particularly non-traditional UI elements. With Submit buttons, links, and list items, I think there’s an expectation and assumption that they’re clickable. Other items like canvas/draggable elements aren't “natural” UI elements, so users wouldn't necessarily know that there are underlying actions associated with those objects.

Cursor changes (changing from normal to pointer) are enough of an identifier for me to know that something is clickable, but most people don’t understand this distinction. It’s not visual enough because it is a subtle change in shape. Unless you’re zeroed in on the arrowhead, you’ll hardly notice it.

Hover states, on the other hand, offer higher visual stimulation because [I would argue that] the brain naturally responds to changes in color more rapidly than it does to changes in shape.

I'd like to hear everyone's opinions with regards to hover states. Do you use them? When do you find them necessary? Or are they just visual-noise?

  • What sort of content are you discussing about including in these hover states? Just visual feedback of the hoverover? Ttooltips, or are you looking to include actual hard data content that you wouldn't be able to access by other means?
    – JonW
    Commented Feb 1, 2013 at 15:54
  • Just the visual feedback in general.
    – Jon
    Commented Feb 1, 2013 at 17:13

11 Answers 11


I vote "yes"! True, hover events shouldn't be depended upon because touch devices are so popular. However, Jon seems to be asking about visual hover states on buttons, which is slightly different.

Visual hover states afford "clickablity". You shouldn't have to click something to find out if it's a button. Users on laptops and desktops expect "clickable" things to react on hover, and having a button "light up" is a useful clue.

Think of it as a form of progressive enhancement. It's useful to those who can use it, and harmless to those who can't!

  • 2
    In fact, I'd go so far as to say that on a desktop browsing environment, the user might almost think there is something amiss if nothing but the cursor changes - we have become so used to hover changes.
    – kontur
    Commented Feb 5, 2013 at 7:18
  • That was my strongest argument/thought. We've grown so accustomed to it that it'd be odd to not have it.
    – Jon
    Commented Feb 5, 2013 at 14:33
  • 4
    Good point on progressive enhancement. I'd add one more thing to "You shouldn't have to click something to find out if it's a button." though; you shouldn't have to hover over something to find find out if it's a button.
    – Adam Lynch
    Commented Feb 7, 2013 at 21:27
  • 1
    I would also say that adding visual hover states on buttons gives the user positive feedback for his action or a sense of an mental award. Commented Feb 16, 2013 at 22:43
  • Having gone from Windows 7 which relied heavily on hover states and often used outlines or panels to indicate buttons, to Windows 8 which often does neither in the "Metro" style interface, I've found Win 8 incredibly frustrating to use at times. It might be what MS wants designers to code for for Win 8, but IMX it's clearly incorrect to do so.
    – Bacon Bits
    Commented Feb 17, 2013 at 23:51

I try to avoid hover states in design as much as possible. The primary reason for that is that they are meaningless on touch devices.

While this may seem like it doesn't apply when you aren't designing for mobile, many people use their tablets or other touch devices to browse the same websites or use the same applications that you would traditionally only use on a computer with a mouse.

By constraining yourself to not use hover events, you not only make the experience good regardless of what device you are using, but you also make is easier to create a touch specific native application later on.

  • 6
    Hover states are still useful on mobile websites. The CSS :hover effectively gets treated as :active when viewed on a mobile device. This gives visual feedback that the user's finger hit the target. This feedback is much more useful on mobile designs because of parallax. As your line of sight deviates from the perpendicular line to the screen, the chances of mis-tapping increases.
    – JoJo
    Commented Feb 1, 2013 at 18:24
  • 2
    @JoJo hover states aren't discoverable on mobile, and tapping is the equivalent of clicking on a computer.
    – JohnGB
    Commented Feb 1, 2013 at 18:33
  • John, in my experience viewing sites that I've designed for desktop on mobile, I believe that JoJo is correct in saying that the hover state [sometimes] acts as the active state. I say sometimes because it's a little finicky and doesn't always show.
    – Jon
    Commented Feb 1, 2013 at 18:59
  • 1
    @Jon I'm not arguing how it translates, I'm arguing about how it makes sense to translate. If hover becomes active, how do you select? Double tap? It breaks the whole touch paradigm.
    – JohnGB
    Commented Feb 1, 2013 at 19:27
  • 1
    @JoJo not always, I don't believe Chrome on Android fires the hover state at all, and Safari's hover state is often awkward
    – Zelda
    Commented Feb 4, 2013 at 17:41

With the emergence of touch being a major way to interact with software, I'd say hover-based interactions are now relegated to 'nice to have enhancements' but should never be a requirement to interact with the software.


I often duplicate the :hover state for :focus, as this is a useful way to indicate focus for a keyboard-only user (which is required to meet WCAG2). It indicates that an item is interactive in some way, without needing a click event which will trigger an action the user hasn't decided to initiate yet. You can just style for :focus without :hover, but in my opinion the intention of the two actions is the same and should have the same visual effect wherever practical.


I also agree in Sam's point of view that hover states can be considered progressive enhancement. I'd just like to clarify that a bit.

From a mobile first perspective hover states don't really server any purpose. So, the UI had better afford clickable behaviors for clickable objects without a hover state (i.e. buttons should look like buttons).

If you can support that notion on a mobile device, that same notion will be supported on desktop/laptop devices as well even before hover states are introduced.

Including a hover state on devices that do support hover -- laptops, desktops, etc. -- will confirm the user's already existing perception that a specific UI element is in fact clickable.

So, to recap:

  1. Build UI elements that are clickable such that they afford clickable behavior for any device.
  2. Use hover states on devices that support hovering to further support the notion that an element is clickable.

Just because you're designing for both desktop and mobile doesn't mean the designs should be the same. Interaction that mobile users might be accustomed to might not be apparent to desktop users.

For example, white cards with a caret on the right side. To mobile users this is obviously something you can tap on. To desktop users, not as much (especially if the card is wider on desktop), but when they hover and see a hover state, it's suddenly obvious that it's clickable.

Especially now that animation is becoming more and more common, a hover state is a basic animation that gives users feedback that they're doing what they intended to do.

Not using a hover state for desktop is lazy and makes people sad.


+1 to Sam for mentioning progressive enhancement.

I'd recommend using hover states if they provide some usefulness that enhances the UI, but they shouldn't ever be needed in order to complete a task.

For example, using them on a product list page to provide a little bit of information about the item when hovering over the image, before the user navigates over. That information should then also be available on the product page itself. It therefore doesn't detract from the experience of the touch-screen user, but adds some additional usefulness for those who do see it. :-)


I don't believe :hover states are essential; UI elements on the desktop have coped without them forever and objects clearly designed to afford clicking (such as the "Post Your Answer" button here on UX.SE) test fine in my own experience. That's not to say it's not helpful; just that it's not essential.

I do, however consider :focus and especially :active states essential; the latter especially is one I see ignored on far too many sites. A clear active state helps the user know the button click was registered immediately (which is extremely important to help users feel that they are directly manipulating an object in the UI). System controls such as buttons and menus have all made that state expected, too, which makes forgetting them even more unforgivable.


I would suggest that hover states provide positive feedback to the user's expectation that the element in question is interactive, thereby removing the potential for more negative feelings of doubt and ambiguity.

Designs deliver a number of cues that an element is interactive - shape, size, position, color, an underline, etc. Different users will require different cues, and perhaps the cumulative effect of a different number of cues, to perceive (and feel confident that) the element is interactive. Changing an element on hover is an opportunity to deliver more cues.

Most (if not all) browsers deliver cues on hover by default, by changing cursor to a pointer. Of course we have control over this and could remove the hover state by removing this effect. But I imagine for most of us (take a moment to imagine it) this would introduce significant doubt into our browsing experience. Browsers (and then designers) have set such a precedent for additional cues on hover that not delivering cues would be a significant contradiction of any previously perceived cues that the element is interactive.

Removal of the browser's default cue is thus a useful example of the value of hover state. For me, the question thus becomes not whether visual cues of interactivity on hover are valuable, but which and how many cues are optimal.

There are some useful familiar precedents, but the answer to this question will depend upon the application and the target audience.


I would suggest hover when there is no icon in the button . If suppose there is a icon colourful in the button that time it is not essential to give hover state to the button. Ex: sign up using Google button.


Hovers are a must for all websites that want any good response online. I've used some websites who ditched the hover status, on my laptop, and it was very frustrating. Any good designer knows that people online are in a rush to find what they want, and if a button won't tell you if it is one or not and you need to open it in a new tab to find out - that is a big failure!

Correct, hovers aren't required for mobile. But, you can always disable them for mobile. Besides, let's not forget that buttons for mobile need to be much bigger than the ones for online. And, aren't they created on two different style sheets anyways?

  • For websites switching the cursor style to a hand (or equivalent) is the hover effect I act on. Commented Mar 16, 2014 at 18:12
  • I believe it still needs to show hover, just a hand confuses the user, as we want the web to work as lifelike as possible, and when we click things if real life - they reflect. Also, from a strategist's point of view, you would want your website to be feel more secure and it's fact that most scam websites don't bother installing the hover effect - therefore, when users don't see the effect they start feeling odd inside.
    – Tzvi
    Commented Mar 20, 2014 at 0:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.