Wording in Interfaces

Role-based questions sort people into buckets the company already decided on. Intent-based questions ask the user what they came here to do — and implicitly promise to help them do it. The phrasing reveals whether the product serves the user or the user serves the product.

"What's your role?" is a demographic question disguised as personalization — it helps the company's analytics dashboard, not the user. The options (Designer, Engineer, PM) are the company's mental model, not the user's. "What will you use Acme for?" flips the frame: now the options describe outcomes the user actually wants (build a website, write and publish). It signals that the product will adapt to their intent, not file them into a segment.

Settings pages are where wording problems compound. Every toggle is a bet on whether the user understands the current state of their own product.

Five issues in one panel. B names the technology ("two-factor authentication"), uses a bare noun ("Notifications"), negates itself ("Disable auto-renewal"), dumps leftovers into "Advanced", and writes a description that repeats the title. A describes the experience ("Require a code to sign in"), gives toggles a clear on-state ("Send me email notifications"), uses positive phrasing ("Renew automatically"), names the real category ("Billing"), and writes a description that adds new information ("Reduces eye strain"). Same settings, completely different clarity.

A button label is a promise — it tells the user what will happen when they click.

"Help" is a noun — it names a category, not an action. "Get Help" is a verb phrase — it tells you what will happen. Same with "Desktop App" (what is it?) versus "Download Desktop App" (now I know what clicking does). "Become a Pro" assumes the user is "not" Pro; "Upgrade Plan" is concrete and actionable.

"Enter keywords" describes the mechanic — type words into a box. The user already knows that. "Search issues, projects, pages" describes the scope — it tells the user what the search covers, which is the thing they actually need to know.

In a search field, the question is never "what do I physically do?" — it's "what can I find here?" Naming the searchable objects turns the placeholder into a feature discovery surface.

"Subscribe to newsletter" repeats the button's job — the user can already see "Subscribe" right there. Placeholder text that echoes the action wastes the one chance to communicate something the user actually needs: what to type.

An example email like "contact@rene.wang" does two things at once: it shows the expected format (an email address) and implicitly answers "what goes here?" without the user having to think. Showing an example is almost always more helpful than describing the field.

The worst error messages communicate failure without offering a path forward. The best ones don't feel like errors at all.

"Invalid input" is a wall. "This email is already registered — try signing in instead" does three things at once: it names the problem (duplicate email), explains why (already registered), and offers a next step (sign in). It transforms a frustrating moment into a helpful one.

The user just did something. The system should echo back what they did — not just that it worked. The difference matters most at scale: three saves in a minute, multiple tabs open, a dozen actions in a session.

A generic "Success!" leaves users wondering what succeeded. Did the save go through? The publish? The delete? A specific confirmation like "Your changes to Project Alpha have been saved" echoes back the action and the object, closing the loop. Vague reassurance is not reassurance — it's noise.

The user had intent — they typed a query, navigated somewhere with a purpose, and came up short. That moment of unmet expectation is the most overlooked in interface design. Most teams treat it as a non-moment. But it's actually the moment with the highest leverage over whether the user tries again or leaves.

"No results found" is a dead end — a closed door with no signage. Echoing back the user's query ("No results for fluxcap") proves the system heard them correctly. Suggesting a next step ("Try a different keyword or check your spelling") opens a new door. Users who hit a helpful empty state try again. Users who hit a bare one leave.

The default instinct is to escalate fear — WARNING, permanent, irreversible, cannot be undone. Three synonyms for the same thing, and the user still doesn't know what they'd actually lose. Fear-based copy becomes noise. Users learn to click through it the way they learn to ignore cookie banners.

B lists factual consequences: 12 posts unpublished, 3 teammates locked out. Now the user can actually weigh the decision. Even the button labels differ — "Cancel" is a generic escape hatch; "Keep project" reframes the safe option as a positive choice. Fear is not information. Consequences are.

Two rules I apply: use consistent nouns throughout, and never use relative dates.

A switches between "invitation" and "invite" three times — a subtle but real inconsistency that erodes trust. It also uses "will expire in 72 hours," forcing the reader to calculate the actual deadline. B uses "invitation" consistently, states the expiration as an absolute date (March 27, 2026), and condenses the security disclaimer from a wall of text into two direct sentences. Every improvement is about respecting the reader's time and attention.

Thanks [@JohnPhamous](x.com/JohnPhamous) for this one.

A changelog is a retention marketing surface disguised as documentation. Every line is an opportunity to remind users why they pay — or an opportunity to sound like a git log nobody reads. The shift is simple: describe the outcome, not the change.

B reads like a git log — it describes what engineers did, using internal language ("support", "rendering issue", "bug"). A speaks directly to the user: "You can now..." and "Your exports now include..." reframe every change as something the user gained. It also names the specific problem that was fixed ("blank pages on Firefox") instead of the vague "bug in PDF export". Users don't care about your bugs — they care about their workflows.

Loading copy is the only moment where the interface has to justify its own existence in real time.

"Please wait..." is empty — it tells you nothing about what's happening or how long it'll take. B names the action ("Generating your report"), sets an expectation ("about 6 seconds"), and shows a live elapsed counter that proves the system is still working. When a delay is unavoidable, the copy's job is to make the wait feel intentional rather than broken.

A disabled button is a desire signal. The user hovered or clicked — they wanted this. That moment of intent is precious, and the tooltip is your one chance to convert it.

"Available on Pro plan" names the gate — it tells the user they can't, full stop. "Unlock custom domains → Pro" names the reward — it echoes back the thing the user wanted and connects it to the path forward. Same five words, completely different emotional direction. The first tooltip explains why you can't. The second reminds you why you'd want to.

The length of a response is itself a message, separate from the words. A one-sentence answer feels confident. A three-paragraph answer feels like it's hiding something — or selling. "Can I cancel anytime?" is the most trust-sensitive question a user can ask.

A is technically accurate and thorough — but thoroughness is the problem. When someone asks "Can I cancel?", they want a yes or no. Three paragraphs of qualifications, edge cases, and support reassurances signal that the real answer is complicated. "Yes. No fees, no questions." is five words and total confidence. It answers the question, addresses the two anxieties behind it (cost and friction), and stops. Brevity is trust.

"Submit" comes from paper bureaucracy — you submit a form, then wait for someone to process it. "Send" comes from conversation — you send a message, and it reaches someone. A contact form is closer to a conversation than a government filing.

"Submit" also strips away the object — submit what? "Send" is direct and conversational. It implies the message will reach someone, not disappear into a queue.

"Next" is directional but empty — next what? It assumes the user remembers the sequence. "Continue to payment" names the destination, which does two things: it confirms where the user is going, and it sets expectations for what they will see.

In a multi-step flow, every click forward is a small trust decision. Naming the destination reduces the cost of that decision to near zero. "Next" asks the user to trust blindly. "Continue to payment" shows them the path.

A leaves a one-word widow — “workspace.” stranded on its own line. The eye registers that imbalance before the brain reads the meaning; the block feels lopsided, half-finished. B says nearly the same thing in two lines of near-equal length, and the composition looks chosen, not happened-upon.

The fix is rarely CSS. text-wrap: balance helps at the margins, but the real move is to rewrite the sentence until it falls into the shape you want. Cut a word, swap an order, replace a phrase. Sculpt the paragraph like marble. “Satisfying” is something users feel as care — even if they can't name it.

Four references to the same concept on one screen, four different words. "Team Members," "users," "teammate," and three different row actions ("Remove," "Kick out," "Delete user"). Each one is fine in isolation. Together, they force the reader to ask: is "Kick out" the same as "Remove"? Does "Delete user" also delete their content? Inconsistency creates micro-doubt at every glance.

B picks one noun ("member") and one verb ("Remove member") and holds them across the whole panel. The user learns the model once and trusts it for every subsequent interaction. A glossary of one term is cheaper than asking every reader to verify whether your synonyms are intentional. Consistency is not a style preference — it's a contract that lets users stop reading carefully.