I Hate Tooltips | Phil Boyd

A quick note before we begin: this post is written in jest. Mostly. I do genuinely hate popup tooltips with a fervor that is probably disproportionate to their harm. But the reason you're reading this is almost certainly because you asked me whether a tooltip would help, or you want me to add one. Consider this my answer.

Let Me Count the Ways

I hate tooltips. For clarity, I'm referring to the surprise pop up, that's anchored somewhere, and demand attention before the user can continue. The problem is always along the lines of "users aren't clicking this CTA, they must not know about it. A tooltip will surely clarify that!". I'm not saying that I die a little on the inside, but I would rather stare at the sun than add a tooltip. Of course, I will add it, but please read my concerns and alternatives before we commit to it.

Here's a list of why I hate them.

Once seen, they're gone.

The user dismissed the tooltip while they were in the middle of something else. Now they need it. It's nowhere. There is no "show me the tooltip again" button, because we thought the user would definitely read our super important message the first time.

The user might not want to be interrupted.

They came to do a job. They're mid-task. A tooltip fires because some condition was met and now your UI is yelling at them. The condition that triggers a tooltip almost never aligns with the moment the user is ready to receive new information.

They block.

Some tooltips require explicit dismissal. Now the user is hostage to information they don't need right now and can't reference later. They also can't find the tooltip, so they're continuting to press the screen and blaming the developer for the app being unresponsive.

They don't get cleaned up.

A feature changes. The tooltip stays. Now you have documentation for a workflow that no longer exists, attached to an anchor point that moved or disappeared entirely. The worst version of this: the UI changed, the anchor is off screen, and the user scrolls to that section and suddenly a tooltip appears from nowhere because the anchor technically loaded. Their entire screen is now disrupted until they close it. Collectively, we've all forgotten about this tooltip.

They accumulate.

The first tooltip is a one-off. So is the second. By the time you have twenty, nobody knows who owns them, when they were added, why some fire and others don't, or which ones are even still relevant. They were added one at a time, each in isolation, and they live in chaos together.

Engineering never gets the time to build the system they require.

A tooltip looks easy to add. And the first one is. But a thoughtful tooltip system requires a priority queue, conflict resolution, sequencing logic, user state tracking, and a way to surface them again on demand. Product will keep adding tooltips to that queue. Engineering will never get the sprint to build the infrastructure. The result is a pile of hacks that each individually looked like a fifteen minute task.

They're a bandaid for bad UI.

If a feature requires a tooltip to explain itself, the feature probably isn't done yet. Tooltips let teams ship something undercooked and defer the clarity problem to a popup. It feels like progress, but it's just a hope that the user is later motivated to figure out what that tooltip was talking about.

What I Actually Prefer

The underlying goal of a tooltip is almost always legitimate: help the user understand something. The question is whether a popup is the right delivery mechanism for that understanding, and it usually isn't.

Build the explanation into the UI. Placeholder text, descriptive labels, inline helper text below a field. These are always available, don't interrupt, and can't be accidentally dismissed. They also force a conversation about whether the label is actually clear enough on its own.

Contextual empty states. If a section is empty because the user hasn't done something yet, that's a perfect moment for guidance. The user's attention is already there. No popup required.

A dedicated onboarding flow. If a user needs to understand several things about a new product or feature, walk them through it deliberately with a modal, a guided tour with explicit navigation, a checklist they control. Let them come back to it. Let them skip it. Give them agency.

Documentation that's easy to find. A persistent help icon that opens a drawer or links to documentation is almost always better than a tooltip. It doesn't interrupt. It's always available. It scales to actual complexity instead of forcing everything into a one-liner.

Better defaults. A surprising number of tooltips exist because the default state of the UI is confusing. Fix the default.

If You Must Build a Tooltip Queue

If you're going to have multiple tooltips in a product, you need a system. Here's what that system has to account for:

Priority. Not all tooltips are equally important. A tooltip introducing a critical workflow change should beat a tooltip about a minor UI improvement. You need a way to encode this and a way to enforce it.

Conflict resolution. What happens when two tooltips want to fire at the same time? You need a rule. "Highest priority wins and the other waits" is a rule. "They all fire simultaneously" is not.

Sequencing. Some tooltips shouldn't fire until others have. If tooltip B explains a button that tooltip A introduced, they need to be ordered. This requires tracking what the user has seen, which requires persistence.

Limit per visit. A user that sees a ton of tips back to back is going to be annoyed. Have a throttle so the user can self explore.

Suppression. Users should be able to say "don't show me these."

Expiration. Tooltips should have an owner and a review date. If no one has reviewed a tooltip in three months, it should be disabled by default until someone confirms it's still accurate. This sounds aggressive. It is less aggressive than having twelve stale tooltips silently misleading users. Better yet, a PR should be generated removing it.

Visibility into the queue. Product should be able to see all the tooltips in flight, their priorities, their trigger conditions, and their current states. If the only way to know what tooltips exist is to read the code, the system is already out of control.

We should build it with thoughtful engineering. If there's no time for that, there's no time for the tooltip.

There are genuinely hard UI problems out there. Clarity, discoverability, onboarding, and progressive complexity are all worth solving carefully. Tooltips are rarely the careful solution. They're the fast one. And in UI, fast solutions have a way of becoming the thing you're stuck with.

If you're still convinced a tooltip is the right move after all of this, I'll build it. I just want you to make that call with both eyes open.