What is microcopy?

Microcopy is all the small snippets of text within an interface. Its primary purpose is to guide users through the interface and help them accomplish their tasks. Some examples include:

• Field labels and helper text
• Text on buttons
• Error messages
• Confirmation or status messages
• Tooltips or contextual help
• Titles and headings

The goal of microcopy is to:

1. Set expectations for what will happen next if a user takes a specific action
2. Inform users what information they need to enter
3. Help people correct errors, so they may continue with their task
4. Reduce anxiety and friction
5. Orient people and tell them what to do next

What makes microcopy good or bad?

Jakob Nielsen’s 2nd usability heuristic states that the design should speak the users’ language. Microcopy is good when it sets clear expectations and tells the user exactly what will happen, what has happened, or how to correct an issue. Bad microcopy is generic, vague, or misleading. The clearest test is whether a user could predict the result of their next click from the words alone. If they can’t, the microcopy isn’t doing its job. When UX Team conducts usability tests, we always ask questions, like “What would you expect to see if you clicked [X button]?” And their response tells us whether the microcopy is clear.

Why you should audit “AI-generated Microcopy”

Bad microcopy isn’t specific to AI. Humans write bad microcopy all the time. You should audit all microcopy, whether it’s written by a human or AI. One thing to remember about AI-generated code or copy is that it’s trained on the entire public internet. That means it basically takes all of that data, and applies an average to your product. It does a decent job. I would say it’s really raised the bar for minimum viable product. However, that generic application isn’t YOUR application. AI has never met your users, has not interviewed stakeholders, has not conducted any information architecture or nomenclature studies. Therefore, you can’t expect it to write clear microcopy. It also “hallucinates” and sometimes makes things up.

Here are a few specific reasons to audit AI Microcopy:

• Accuracy. AI fills in what it doesn’t know with assumptions.  It might assume that you’ll send a confirmation email when, in reality, there is no such email confirmation.
• Task success. Unclear instructions hinder task success. Baymard found 98% of e-commerce sites use generic validation errors, and vague wording left test participants taking up to five minutes on simple sign-in errors. Some gave up.
• Nomenclature. AI bases its copy on training data, which is not specific to your product or your users. What it calls “Register” might really be a misnomer if they are already registered and just need to activate their account. To be fair, humans are guilty of using internal jargon that their users don’t understand, too.

The goal is to write clear instructions, not necessarily to make it look human-written. Use the tells below as a fast way to find strings that need a closer look.

What to look for

Check every string for the patterns below. A single string often has more than one.

Better alternatives

Most fixes replace a generic phrase with what actually happens. The pairs below show this by component.

For errors and confirmations, a dependable structure is what happened, why it happened if that helps, and what to do next. Anything that doesn’t serve one of those can usually go.

Quick checklist

Run each string through these before it ships.

• Does the user know what will happen before they click?
• Does every button use a verb + object (no Submit, OK, Continue)?
• Does every error say what happened, if data is safe, and what to do next?
• Are filler openers, emoji, exclamation points, and buzzwords gone?
• Does each term match the nomenclature everywhere it appears?
• Is every promise true in the current build?
• Can you say it in fewer words without losing clarity?
• Does a screen reader read it correctly?
• Have you tested it on every screen, including edge states?

Want to get it (closer to) right the first time?

You might have heard of design.md or even be using one in your application right now. Design and development teams use design.md when creating ai-generated user interfaces to instruct the agent with colors, typography, components, etc. But, did you know microcopy rules belong in there, too? Here are 10 microcopy rules to get you started:

1. Never describe a feature, notification, timeframe or system behavior that isn’t in the spec. If you don’t know what happens, write [TODO: confirm behavior] instead of guessing.
2. Be concise – use the shortest version that’s still clear.
3. Button labels should be [action + noun]. Describe what is happening and what it applies to. Good Examples: “Place order”, “Save as Draft”, “Discard Changes.” Bad examples: “Submit”, “Yes”, “No.”
4. The confirm button in a dialog repeats the action. Example: “Delete files,” not “Yes”.
5. Every icon-only button needs an accessible label.
6. Errors should state what happened, whether the users’ data is safe and how to fix the error (if possible)
7. Name the specific problem: “Enter a data after today,” not “Invalid Input”
8. No humor, emojis, “Oops” or “uh oh” in error messages
9. For destructive actions, state what will be deleted, how many items, and whether it can be undone. “Delete 12 files? This action cannot be undone.”
10. Form labels are nouns, not instructions or questions. “Company name,” not “Enter your company name, ” and not “What is your company name”

Of course, there are many other rules you could add. Still, these 10 will go a long way toward better microcopy from the get-go.