Skip to main content
Back to Blog
Strategy9 min read

Microcopy Matters: How Button Labels and Error Messages Shape the User Experience

Microcopy is the smallest text on your site with the biggest impact on trust. Here's how to write button labels, error messages, and tooltips that actually work.

E
Excelle Escalada
Digital Experience Architect

The moment a user decides to give up

It usually isn't a big thing. It isn't a confusing navigation or a poorly designed form. It's a moment where a tiny piece of text says the wrong thing, creates uncertainty, or makes the user feel vaguely unsafe.

"Submit" on a button that's about to send personal information. An error message that says "Invalid entry" without telling them what a valid entry looks like. A confirmation modal that says "Are you sure?" with the only options being "Yes" and "No."

These are microcopy failures. And they're everywhere.

What microcopy is (and why it matters more than you think)

Microcopy is the small, functional text on your website: button labels, error messages, placeholder text in form fields, empty states, loading messages, tooltips, and confirmation dialogs.

It isn't blog content or marketing copy. It's the operational language that users encounter at moments of decision and action. And because users encounter it precisely when they're deciding whether to proceed or abandon, it has a disproportionate impact on completion rates, trust, and satisfaction.

Studies from CXL Institute and other UX research organizations have found that small microcopy changes can move conversion rates by double-digit percentages. The difference between "Submit" and "Get my free guide" on a form button. The difference between "An error occurred" and "Your credit card number should be 16 digits without spaces."

Most of that text is written in 30 seconds by a developer filling in a label field. It deserves more.

Button labels

Buttons are the most common microcopy element and the most frequently written badly. The default instinct is to name the action in general terms: "Submit," "Continue," "Send," "Click here."

These labels fail because they're writer-centered. They describe what the button does mechanically, not what the user gets from clicking it.

The principle: A button label should complete the sentence "I want to ___."

Examples:

Default labelBetter label
SubmitSend my application
ContinueGo to checkout
Click hereDownload the report
Sign upCreate my free account
SendSend message to [Organization]

The more specific the label, the more it confirms for the user that they're about to do what they intend to do. Specific labels reduce hesitation and increase follow-through.

Exception: Short labels like "Save," "Cancel," and "Delete" work well because they're already specific and familiar in context. You don't need to rewrite every single button, just the ones that create ambiguity.

Error messages

Error messages are high-stakes microcopy. They appear when something has gone wrong, which means the user is already frustrated. Bad error messages turn frustration into abandonment.

A useful error message has three components:

  • What went wrong — stated in plain language, without accusation ("We couldn't verify your email address" not "Invalid email address")
  • Why it went wrong — if it isn't obvious ("Email addresses need an @ symbol and a domain, like [email protected]")
  • How to fix it — actionable next step ("Try again or contact support if you need help")
  • Examples:

    Before: "Error. Please try again."

    After: "We ran into a problem processing your payment. Please check your card number and expiry date and try again. If the issue continues, your bank may have flagged the transaction."

    The second version gives the user something to do. The first version leaves them guessing.

    Before: "Invalid entry in field 3."

    After: "The postal code you entered doesn't look right. Canadian postal codes follow the format A1A 1A1 (for example, M5V 3A8)."

    Technical note: Never surface raw error codes or system messages to users (e.g., "HTTP 500" or "NULL reference exception"). These are meaningless to most users and erode trust.

    Placeholder text

    Placeholder text appears inside form fields before users start typing. It's frequently misused.

    The most common mistake is using placeholder text as a substitute for form labels. This is an accessibility failure worth catching early: screen readers may not announce placeholder text, and the text disappears as soon as the user starts typing, leaving users who type slowly or need to double-check without any guidance.

    Use placeholder text for:

  • Brief formatting hints ("MM/DD/YYYY" for a date field)
  • Example values that clarify expectations ("e.g., Ottawa, ON")
  • Brief search suggestions ("Search by name or ID number")
  • Don't use placeholder text for:

  • Field labels (always use a visible <label> element)
  • Instructions the user needs to refer to while typing
  • Legal requirements or validations
  • Empty states

    Empty states appear when there's no content to show: an empty inbox, a search with no results, a new account with no saved items. They're often treated as an afterthought, but they're prime real estate for guiding users toward meaningful action.

    A good empty state has three parts:

  • A plain-language explanation of what's happening
  • A reason why (if not obvious)
  • A call to action that moves the user forward
  • Before: "No results found."

    After: "We didn't find anything matching 'municipal accessibility policy.' Try different keywords, or browse our full document library."

    Before: "Your cart is empty."

    After: "You haven't added anything yet. Browse our services or start with a free consultation."

    Empty states that guide feel like help. Empty states that just state a fact feel like a dead end.

    Confirmation dialogs

    "Are you sure?" is the most common confirmation dialog and the least useful. It creates a friction point without giving the user the information they need to decide confidently.

    A good confirmation dialog describes:

  • What exactly is about to happen
  • Whether it's reversible
  • The specific consequence
  • Before: "Are you sure you want to delete this? This action cannot be undone."

    After: "Permanently delete this document? Your team will lose access immediately. This can't be undone."

    The "before" version is technically accurate. The "after" version is specific about scope ("your team") and timing ("immediately"), which helps the user make an informed decision rather than just a habitual one.

    How to audit microcopy on your site

    You don't need a full UX audit to identify the worst microcopy failures. Walk through your site's highest-traffic user flows and note every piece of functional text you encounter:

  • Every button label
  • Every form field label and placeholder
  • Every error message (you may need to deliberately trigger errors)
  • Every confirmation dialog
  • Every loading or processing message
  • Every empty state
  • For each piece of text, ask: does this tell the user exactly what will happen, what they should do, and why? If not, it's a candidate for revision.

    One afternoon of this work, done systematically, will surface more improvements than a month of analytics review.


    If you want a microcopy audit or a UX writing review of your site's most critical flows, get in touch and we can make a real difference in your completion rates.

    Share this article

    More Articles