The problem with tooltips and what to do instead

There’s been some comments about this on Twitter.

Tooltips are messages that appear when the user hovers over part of an interface—usually an icon—to explain how certain things work or what they mean.

They then disappear when the user hovers off the element.

Various tooltip illustrations

Although they allow you to squeeze additional information on screen, they have a number of problems.

Here I’ll explain some of the downsides of tooltips and what to do instead.

# 1. They’re hard to spot

Some users won’t notice a tooltip which means there’s a high risk they’ll never see the content it contains.

# 2. They require effort

Let’s say users need additional information to help them satisfy a password field with complex rules. Making users reveal the content first is an unnecessary burden.

Revealing content requires effort

# 3. They obscure the screen

Tooltips are shown on top of the screen blocking some of the interface.

This means you can’t read the tooltip and operate the rest of the screen at the same time.

Part of the screen is obscured

Users have to work hard to remember the hint, or switch between 2 modes of operation repeatedly.

# 4. They could be cropped in small screens

As tooltips are overlaid, there’s a chance they’ll be cropped by smaller viewports.

Tooltips could be cropped

# 5. They don’t work well with speech recognition

Tooltips that consist of icons need an accessible label. But even if you have one, voice users have to interpret what they see and guess what it is.

Icons are hard to target via speech recognition software

Imagine a bell icon. It’s not clear whether users should say ‘Click bell’, ‘Click notifications’ or something else entirely in order to activate it.

# 6. Revealing content on hover is inaccessible

Firstly, you need to use a mouse or other pointing device to use a tooltip which excludes keyboard and touch screen users.

Secondly, hovering is not always an intention to activate a control. The user might move the cursor over a tooltip which accidentally activates it.

Thirdly, it requires fine motor skills to operate. Users have to move their mouse accurately over the hit area and hold it steady to avoid accidentally hiding it.

Fourthly, it’s not possible for screen magnifier users to move their field of view without hiding the tooltip.

Finally, users can’t select or interact with the content within the tooltip.

You could provide a comparable experience for keyboard users by showing the tooltip on focus. But this is unconventional and still excludes touch screen users.

# What to do instead

# 1. Do the hard work so users don’t have to

Having content just to help users understand your interface is a sign of bad design.

If you’re using an icon to convey meaning, use text instead, or use icons and text together.

Top: just an icon (bad). Middle: just text (good). Bottom: text and icon (good).

If you’ve got one complex question, can you make it simpler by asking several shorter questions?

Either way, do the hard work to make it simple.

# 2. Just show the extra content

If you really do need to provide users with clarification just show the content.

Top: content in a tooltip (bad). Bottom: content inline (good)

Give users what they need when they need it.

# 3. Use a better pattern for toggling content

If (1) and (2) don’t work, use an inline toggle component.

A toggle component

This is better because it:

  • doesn’t rely on iconography alone
  • won’t be cropped by the viewport
  • doesn’t obscure content
  • is activated on click which works well in all contexts

# Summary

While tooltips provide a way to hide and show content, needing to clarify how your interface works indicates bad design.

At best, tooltips make users jump through a series of hurdles in order to access the content. At worst, they’re not seen and totally inaccessible.

A better alternative is to just show the content in situ, or better yet, design the interface so that users don’t need the additional guidance in the first place.

If all else fails, use an inline toggle component. It provides all of the benefits of progressive disclosure without the pitfalls of tooltips.

Thanks to Amy Hupe for editing this.