Writing Clear Interface Text and Error Messages

Words are part of the interface

Every label, prompt and message in an app is a design decision. People rarely notice good wording, because it simply lets them get on with things. They notice poor wording immediately: a button that says “Submit” when they wanted to save a draft, an error that says “Something went wrong,” a warning written in the language of the code.

This kind of short interface text is often called microcopy. It is small in volume but large in effect, because it appears exactly at the moments people are deciding something or feeling stuck.

Principles for all interface text

• Be specific. Say what will happen. “Save changes” beats “OK.”
• Be brief. Phones have little room, and people read in glances.
• Use everyday words. Prefer “sign in” over “authenticate,” and “photos” over “media assets.” Avoid internal jargon and abbreviations.
• Be consistent. Pick one term and keep it. If it is “Delete” in one place, do not call it “Remove” or “Discard” elsewhere unless they truly differ.
• Put the important word first. People scan the start of a line.
• Be polite, not chatty. A friendly tone is fine, but jokes in a serious moment grate, and forced cheerfulness feels insincere.
• Write for translation. Avoid idioms and puns. Leave room because many languages need longer text.

Button labels

A button label should describe the action, ideally with a verb. Some examples of the difference:

The labels on a confirmation dialog matter a great deal. “Cancel” and “OK” invite mistakes, because people may not recall what the question was. Repeating the action in the buttons, such as “Keep editing” and “Discard draft,” makes the choice plain even for someone reading quickly.

Avoid labels that make declining feel shameful, such as “No thanks, I don’t like saving money.” Both options should be neutral and equally easy to tap. That is part of treating people fairly and it avoids sliding into manipulative design.

Prompts and instructions

Tell people what you need and why, in the place where they need it. A field labeled “Email” with a hint such as “We’ll send your receipt here” is better than a bare label. Keep the label visible while typing; inline hints that disappear force people to remember what the field was for.

Explain unusual requests. If the app asks for access to something sensitive, say plainly what it is for, as discussed in guidance on app permissions. If a password has rules, show them before the person fails them, not after.

Avoid the temptation to over-explain. If a screen needs a paragraph of instructions, the design may need simplifying. The words should support the layout, not rescue it.

Error messages

Errors are where wording matters most, because the person is already interrupted and possibly worried. A good error message answers three questions: what happened, why (if known), and what can I do about it.

Principles

1. Say what went wrong in plain language. “We couldn’t save your note because you’re offline” is better than “Error 500.”
2. Offer a next step. “Check your connection and try again,” with a button that retries.
3. Do not blame. “Invalid input” feels accusatory. “Enter a date like 12/05/2026” helps. Phrase it as what the app needs.
4. Be calm. Avoid exclamation marks, capital letters and alarming words unless the situation is truly serious.
5. Show it where it happened. Put a field error next to the field, not in a distant banner. Do not rely on color alone; add an icon or text.
6. Preserve the person’s work. Never clear a long form because one field was wrong.
7. Avoid technical codes in the main message. If a code helps support staff, place it in a small line at the bottom, which can be useful for user support.

Examples

Only promise safety, like “Your saved items are safe,” when it is true. A reassuring message that turns out to be false is worse than an honest one.

When something is the app’s fault, say so briefly and do not push the work onto the user. Many connection problems are a normal part of mobile use, so designing for poor connections, as in offline mode, reduces how often these messages appear at all.

Empty states, confirmations and success messages

• Empty states are an opportunity. Instead of a blank screen, say what will appear here and how to start: “No saved places yet. Tap the heart on any place to save it.”
• Confirmations should be proportionate. A small, brief message like “Saved” is enough for routine actions. Reserve full dialogs for risky or irreversible ones.
• Success messages should not linger or demand a tap.
• Destructive actions should say exactly what will be lost: “Delete this account and all its data? This cannot be undone.”

Tone and responsibility

Wording influences behavior. Phrases built on urgency or guilt, such as “Last chance!” or “Your friends are waiting,” push people to act against their own interests. Prefer honest, neutral language, which fits the principles of ethical app design. This is especially important with notifications, where plain, factual text is easier to live with, and people can tune them through notification settings.

Also pay attention to inclusivity. Avoid assuming gender, age or ability, and write so that screen readers make sense of it. Labels should work when read aloud out of context, so “Read more” repeated ten times is unhelpful; “Read more about backups” is better. Such details are part of inclusive design.

Reviewing your text

1. Read every string aloud. If it sounds strange, rewrite it.
2. Ask someone unfamiliar with the app to explain what each button would do.
3. List every error the app can produce and write each one deliberately.
4. Check for consistency by searching for different words that mean the same thing.
5. Test the text with large font sizes, since longer wording may no longer fit, and make sure readability holds up.

Clear words cost nothing to ship and save a surprising amount of confusion. Treat them with the same care as the layout.