The interface that explains itself

Every tooltip is a small confession. It says: this control does not communicate its own purpose, so we have attached a paragraph to it. Sometimes that is genuinely the right call. Far more often it is a design that stopped one revision early, and the tooltip is the patch.

The explanation budget

Think of every screen as having a fixed budget for explanation. You can spend it on labels, on empty states, on help text, on onboarding, or on making the thing self-evident. The budget is fixed but the returns are not — money spent on making the object itself legible keeps paying, and money spent on text about the object has to be re-earned by every new user, in every language you translate into.

When I audit a product, I count the words of instruction on the primary flow. It is a crude measure and it is almost always revealing. A checkout with three hundred words of guidance does not have a copy problem.

What replaces the tooltip

Usually one of four things. A better label, which is free. A visible default that demonstrates the expected input. A preview of the consequence, so the control explains itself by showing its effect. Or removing the option entirely, because the tooltip was compensating for a decision the product should have made on the user's behalf.

That last one is the uncomfortable option and the most frequently correct.

When the tooltip is right

Domain terms that the user must learn anyway — a tax classification, a clinical measure, an industry unit — deserve a definition close at hand. The test is whether the explanation teaches something durable about the domain, or merely patches something local about your interface. The first is a service. The second is debt.

The goal was never zero words. It was to stop using text to apologise for form.