Microcontent: Writing Labels, Tooltips, and Buttons

The most-read writing on your website is not your blog, not your homepage headline, not your carefully wordsmithed mission statement. It’s the word on the button. It’s the label on the form field. It’s the little line under the input that explains what format the date should be in. This is the writing people actually interact with, thousands of times a day, and on most sites it’s the writing nobody wrote. It just accumulated, one default at a time, out of whatever the developer typed while thinking about something else.

People in the trade call these fragments microcontent, which makes them sound minor. They’re the opposite. A button label is read at the exact moment a person decides whether to act. A field label is read at the exact moment a person decides what to type. No paragraph anywhere on your site gets read at a moment of such consequence. Word for word, nothing you publish works harder.

And word for word, nothing is harder to write. This surprises people, but it shouldn’t. In an essay, if a sentence is unclear, the next sentence gets another chance. Microcontent has no next sentence. A button gets one to three words to convey what will happen, and it has to be understood instantly, by someone who is not reading carefully, possibly on a small screen, possibly annoyed. Writing at that compression is closer to designing than to writing. As with the famous apology about not having time to write a short letter, brevity is the expensive part.

The single most useful rule I know for buttons is to label the outcome, not the mechanism. “Submit” is a mechanism word; it describes what the form does internally, which the user doesn’t care about. “Create account,” “Send message,” “Download report” — these describe what the person gets. The test is to imagine the user silently completing the sentence “I want to…” with the button’s label. “I want to submit” is nobody’s actual desire. “I want to download the report” is. This matters most at scary moments: a button that says “OK” under a question like “Delete this project?” forces the user to reconstruct what OK will do. A button that says “Delete project” carries its own warning.

Field labels have their own discipline: name the thing, not the instruction. “Email” beats “Enter your email address” — the input box already implies entering, so the extra words are pure noise the eye has to push through. If a field needs an explanation, and some genuinely do, put it in a persistent line of help text near the field rather than in placeholder text inside it. Placeholder text vanishes the moment someone starts typing, which means the instruction disappears exactly when the person is acting on it. Someone interrupted mid-form comes back to a box containing half an answer and no label. Placeholder-as-label is one of the most common defects the audits I run turn up, and it’s common because it looks so clean in the mockup, where nobody has typed anything yet.

Tooltips are where teams hide their failures. A tooltip is a fine place for genuinely secondary detail: why you ask for a phone number, what a technical term means. But when a tooltip is required to make sense of the control it’s attached to, the control is misnamed, and the tooltip is a patch over the misnaming. Tooltips also barely exist on touch screens, where there’s nothing to hover. Every time I’m tempted to add one, I first try to fix the label it would be explaining. Most of the time the tooltip turns out to be unnecessary, because the confusion it addressed was manufactured two words earlier.

The subtlest microcontent problem isn’t any single label. It’s inconsistency between labels. If one screen says “Sign in” and another says “Log in,” if the thing called a “workspace” on the dashboard is called a “team” in settings, each label may be fine alone while the set teaches users to distrust your words. People do build a small mental dictionary of your interface, and every synonym is an entry that might or might not mean something different. The fix is dull and effective: keep a list of the words your product uses for things, and use those words everywhere, in the interface, the docs, and the marketing site alike.

The reason microcontent stays bad is structural. It has no natural author. Marketing owns the homepage, engineering owns the code, and the words on the buttons sit in the gap between them, written last, reviewed never. So the advice I’d give any small team is cheap: extract all your interface strings into one file and read them straight through, top to bottom, as a text. It’s an odd document — a poem of imperatives — and its flaws are invisible in context but glaring in a list. Every “Submit,” every “Click here,” every placeholder posing as a label stands up and identifies itself.

An interface is a conversation your site has with strangers while you sleep, held entirely in fragments. Most sites have never once listened to their own side of it.