Error Messages and UX Microcopy: How to Write Interface Text That Helps Users Recover

Every product has errors. Users mistype email addresses, upload files that are too large, lose their internet connection, and click buttons they do not have permission to use. Systems fail, servers time out, and payments are declined. Errors are a normal part of any interface.

What separates good products from frustrating ones is not the absence of errors, but how they are communicated. A clear, helpful error message turns a moment of frustration into a quick recovery. A vague or technical error message leaves users confused, anxious, and often stuck.

Error messages are part of a broader category of interface text known as microcopy: the labels, hints, confirmations, and messages that guide users through a product. Microcopy is small, but its impact on usability is large.

What Makes an Error Message Good

A good error message answers three questions:

1. What happened? Describe the problem clearly.
2. Why did it happen? Explain the cause, if it is useful for the user to know.
3. What can I do? Tell the user exactly how to fix the problem or what to do next.

Compare two versions of the same message:

• "Error: Invalid input."
• "That email address is missing an @ symbol. Check the address and try again."

The first tells the user something went wrong but gives no indication of what or how to fix it. The second identifies the problem, implies the cause, and provides a clear next step.

Most poor error messages fail on the third question. They describe the problem but leave users to figure out the solution on their own.

Use Plain Language

Error messages should be written for users, not developers. Technical terms, error codes, and system jargon mean nothing to most people and can make them feel that they did something seriously wrong.

Avoid messages like "Error 500: Internal server exception" or "Null reference in request handler." Instead, describe what the user experienced in everyday language: "Something went wrong on our end. Please try again in a few minutes."

If an error code is useful for support purposes, include it as secondary information, such as in small text below the main message, rather than as the main content. That way, users get a clear explanation and support teams can still identify the issue.

Be Specific

Generic error messages are one of the most common usability problems. "Something went wrong" is sometimes unavoidable for unexpected system errors, but it should not be used when the cause is known.

If a file upload fails because the file is too large, say so and state the limit: "This file is 12 MB. The maximum size is 10 MB." If a password does not meet requirements, state which requirement is not met. If a username is already taken, say so and, where possible, suggest alternatives.

Specificity saves users time and reduces support requests. Every vague error message is a potential support ticket.

Don't Blame the User

The tone of an error message matters. Messages that imply the user made a mistake, even when they did, can feel accusatory and frustrating.

Avoid phrases like "You entered an invalid date" or "You failed to complete the required fields." Instead, focus on the problem and the solution: "Enter a date in the format DD/MM/YYYY" or "Please complete the highlighted fields."

When the system is at fault, take responsibility: "We couldn't save your changes. Please try again." A brief acknowledgment of the inconvenience can help, but avoid excessive apologies that delay the useful information.

Match Tone to Severity

Not every error deserves the same tone. A minor validation error in a form should be calm and brief. A failed payment or a data loss warning deserves a more serious, careful tone.

Humor can make a product feel friendly, but it rarely belongs in error messages. A playful message about a failed payment or lost work can feel dismissive to a frustrated user. If you use a lighter tone, reserve it for low-stakes situations, such as a page not found, and keep the helpful information front and center.

Place Errors Where Users Will See Them

The location of an error message affects whether users notice it and understand what it relates to.

For form fields, display error messages directly beside or below the relevant field. Highlight the field with color and an icon, and keep the user's input so they can correct it rather than starting over.

For errors affecting a whole page or action, such as a failed save, use a clearly visible banner or notification near the top of the relevant area. For critical errors that block progress, a dialog may be appropriate, but use dialogs sparingly, since they interrupt the user's flow.

Make sure error messages are announced to screen reader users, and never rely on color alone to communicate an error.

Prevent Errors Before They Happen

The best error message is one that never needs to appear. Good microcopy can prevent many errors before they occur.

• Explain requirements upfront. Show password rules, file size limits, and format requirements before users encounter them.
• Use helpful placeholder examples. Show the expected format in input fields, alongside a visible label.
• Constrain inputs. Use date pickers, dropdowns, and input masks where appropriate to prevent invalid entries.
• Confirm destructive actions. Ask users to confirm before deleting important data, and clearly describe what will be deleted.
• Offer undo. Where possible, allow users to reverse actions instead of asking for confirmation every time.

Prevention reduces frustration and support requests, and makes the product feel more thoughtful.

Writing Other Microcopy

The same principles apply to other kinds of microcopy throughout an interface.

Button labels should describe the action they perform: "Save changes," "Send invoice," "Delete project." Avoid vague labels like "OK" or "Submit" where a more specific label is possible.

Confirmation messages should state what happened: "Your changes have been saved" or "Invoice sent to client@example.com."

Empty states should explain what the screen is for and how to get started.

Tooltips and helper text should clarify features or fields without overwhelming users with information.

Across all microcopy, aim for clarity, brevity, and consistency. Use the same terms for the same concepts throughout the product, and write in a voice that reflects your brand without sacrificing clarity.

Creating Microcopy Guidelines

As products grow, microcopy can become inconsistent, especially when multiple people write it. A simple set of guidelines keeps it coherent.

Document your voice and tone, preferred terminology, capitalization rules, and patterns for common messages, such as errors, confirmations, and empty states. Include examples of good and bad messages. Even a one-page guide can significantly improve consistency.

Auditing Your Error Messages

To improve error messages in an existing product, start by collecting them. Trigger common errors yourself, review support tickets for confusing messages, and ask developers for a list of error states in the code.

Evaluate each message against the three questions: what happened, why, and what to do. Rewrite messages that fall short, prioritizing errors that occur most often or block important tasks.

Good microcopy rarely gets noticed, but users feel its effects. When errors are explained clearly and recovery is easy, users stay confident and keep moving — and that confidence is one of the most valuable things an interface can provide.