Ask a model to write an error message and it will hand you something cheerful, generic, and quietly useless: "Oops! Something went wrong. Please try again." It is grammatical, it is friendly, and it tells the user nothing about what broke, why, or how to recover. This is the signature failure of AI-written UX copy, and it shows up across every microcopy surface a product has. This lesson uses Claude with a structured voice-and-tone prompt to draft three microcopy patterns - empty states, error messages, and success confirmations - then runs a brand-voice audit across twenty existing strings to surface the drift the model introduces, rewrites the worst five, and names the failure modes specific to AI UX writing so you can catch them on sight. You leave with a voice-and-tone audit and a microcopy pattern library committed to your design-system docs, which is the difference between content design and autocomplete.

The Cheery Bot That Helps No One

Start with the error message, because it is where the failure is loudest. A user just tried to save a document and the save failed because their session expired. The model-written message reads: "Oops! Something went wrong. Please try again." Read it as the user would. They do not know what went wrong. "Try again" will fail again, because trying again does not refresh an expired session. The exclamation point and the word "oops" are performing friendliness at a person who just lost work and is now stuck in a loop. The copy is cheerful at exactly the moment cheerfulness reads as the product not taking the problem seriously.

Compare the copy a content designer would write: "Your session expired, so we couldn't save your changes. Sign back in and we'll restore your draft." This version names the cause (session expired), states the consequence honestly (changes not saved), and gives a recovery path that actually works (sign back in), plus a reassurance that addresses the real fear (your draft is not gone). The difference is not tone polish. The difference is that the content designer understood the user's situation and the model did not. The model generated what an error message sounds like; the designer wrote what this error message is for. It is the generation-versus-understanding gap again, now in words.

Why AI UX Copy Fails in Predictable Ways

The failures are not random, which means you can name them and catch them. Across empty states, errors, and confirmations, AI-written microcopy fails in four recurring ways, and learning the four is most of the skill.

The Four AI UX Copy Failure Modes

1. Cheery-bot tone. The model defaults to upbeat friendliness regardless of context, so it greets an error with "Oops!" and a deletion with "Yay!" The tone is context-blind. Real UX voice modulates: calm and clear in errors, encouraging in empty states, quietly confirming in success. A model that is cheerful everywhere is tone-deaf everywhere.
2. Generic verbs. AI copy leans on weak, all-purpose verbs - "manage your settings," "explore your options," "get started" - that say nothing specific. Good microcopy uses the exact verb for the exact action: "rename your workspace," "invite a teammate," "restore your draft." Generic verbs are the linguistic equivalent of placeholder content; they look like copy and carry no information.
3. Missing recovery paths. The most damaging failure. AI error messages frequently describe a problem without telling the user how to fix it, or offer a recovery ("try again") that does not match the actual cause. An error message that does not lead to recovery is not an error message; it is a dead end with good grammar.
4. Missing accessible alternatives. AI copy often assumes sight and a pointer - "click the button below," "see the chart above" - producing copy that breaks for screen-reader users or fails when the referenced element is not where the copy assumes. Accessible microcopy does not rely on visual position or a single input modality.

Notice that all four are failures of understanding the user's situation, not failures of grammar. The model writes fluent English every time. Fluency is its high-frequency strength. Situational appropriateness - the right tone, the exact verb, the working recovery, the accessible phrasing - is the low-frequency, high-stakes part it cannot reliably supply.

An AI writes what a message sounds like. A content designer writes what the message is for. Fluent and friendly is the model's floor; situationally correct and genuinely helpful is the designer's job.

The Structured Voice-and-Tone Prompt

The fix is not to stop using the model; it is to give the model the understanding it lacks, the same way the brand-anchor lesson gives an image model reference images. For copy, the anchor is a structured voice-and-tone prompt that encodes the brand's actual voice, the specific surface, and the situational requirements, so the model's fluent output is steered toward correctness instead of toward its cheerful generic center.

A good voice-and-tone prompt has four parts. First, the voice definition: not adjectives like "friendly" but concrete rules with examples - "we are plain and direct; we say 'sign in' not 'authenticate'; we never use exclamation points in errors; we address the user as 'you' and ourselves as 'we.'" Second, the surface and situation: "this is an error message shown when a save fails due to an expired session; the user has likely lost unsaved work and is anxious." Third, the required elements: "name the cause, state the consequence honestly, give a recovery path that resolves this specific cause, reassure about data where true." Fourth, the constraints: "under 160 characters, no exclamation points, no 'oops,' recovery action must be a real action available on this screen, no references to visual position."

With that prompt, the model's fluency becomes useful, because it is now fluent in service of the right requirements. It will still occasionally drift toward cheeriness or a generic verb, which is why the audit that follows is not optional, but the structured prompt moves the output from "autocomplete" to "draft worth editing," which is exactly where you want AI in content design.

Drafting the Three Microcopy Patterns

Run the structured prompt across the three patterns that recur in every product, and you will see how the requirements differ by surface.

Empty states. The requirement is to orient and encourage. An empty state is not an error; it is a teaching moment, the first time a user sees a feature with no content yet. The model's cheery-bot default ("Nothing here yet!") wastes it. The structured prompt asks for orientation plus a single clear next action: "You haven't created any projects yet. Create your first project to start organizing your work." It names the state, explains it without alarm, and offers the exact next verb.

Error messages. The requirement is the four-part structure from the session example: cause, consequence, recovery, reassurance. This is where the missing-recovery-path failure is most dangerous, so the prompt's recovery constraint does the heavy lifting. Every error draft is checked against the question "does the recovery path actually resolve this specific cause," and any that fails is rewritten or rejected.

Success confirmations. The requirement is to confirm quietly and, where useful, point to the next step. The model over-celebrates ("Success! Hooray!"); the right copy is calm and specific: "Your changes are saved." Where there is a meaningful next action, name it: "Your project is published. Share the link with your team." The failure to avoid here is celebrating routine actions, which trains users to ignore confirmations that should be reassuring.

The Brand-Voice Audit Across Twenty Existing Strings

Drafting new copy is half the lesson. The other half is auditing the copy that already exists, because most products have accumulated microcopy from many authors and tools over years, and the drift is real. Pull twenty existing strings from across the product - errors, empty states, buttons, confirmations - and run each through a voice-and-tone audit against the brand voice definition and the four failure modes.

The audit is a fixed check per string: Does the tone match the surface, or is it cheery where it should be calm? Are the verbs specific or generic? If it is an error, does it offer a working recovery path? Does it rely on visual position or a single input modality? Score each string pass or fail on each dimension, and you will find that a meaningful fraction fail at least one. Some of those failures are old human-written copy; some are AI-written copy that shipped without editing; the audit does not care about the author, only about whether the string serves the user. That neutrality is the point - the audit is about the copy, not about blame.

Lay the twenty out together, the way the drift audit lays out images, because voice drift, like visual drift, is most visible in aggregate. Twenty strings side by side reveal whether the product speaks with one voice or with the ten voices of everyone and everything that ever wrote into it.

Rewriting the Worst Five

From the audit, take the five strings that fail hardest and rewrite them, using the structured prompt as a drafting aid and your judgment as the final authority. The rewrite is where the lesson becomes concrete craft. A string like "Error: operation failed" becomes "We couldn't send your invite because that email is already on your team. Try a different address." A button reading "Submit" becomes "Send invite," matching the exact action. An empty state reading "No data available" becomes "No results yet. Adjust your filters to see more." Each rewrite fixes a named failure: generic verb, missing recovery, cheery vagueness.

The discipline in the rewrite is to fix the failure, not to add polish. The temptation, especially with a model in the loop, is to make the copy cleverer or warmer. Resist it. The user does not want clever; they want to understand their situation and know what to do. The best rewrite is often the plainest one, the one that names the cause and the recovery and then stops. Plain and correct beats warm and vague every time, and a model left to its own devices reliably produces warm and vague.

The Artifact: The Audit Plus a Pattern Library in the Design System

The named artifact is two things committed to your design-system docs. The first is the voice-and-tone audit itself: the twenty strings, their pass or fail per dimension, and the five rewrites, documented so the audit is repeatable and the standard is visible. The second, and the one that compounds, is a microcopy pattern library: documented patterns for empty states, error messages, and success confirmations, each with the required structure, the constraints, and approved examples, committed to the design system where every designer and every model can read them.

The pattern library is what turns this from a one-time cleanup into a standard. When the empty-state pattern is documented in the design system - "name the state, explain without alarm, offer the exact next action" - the next designer who writes an empty state has the pattern to follow, and the next time someone prompts a model for microcopy, the pattern becomes the structured prompt. The library is the institutional memory that keeps the product's voice consistent as people and tools change, the same role the brand-anchor reference set plays for images and the fingerprint note plays for models. Content design at scale is not writing every string by hand; it is documenting the patterns so well that every string, whoever or whatever drafts it, comes out in one voice and genuinely helps.

Why This Is Content Design, Not Autocomplete

The line this lesson draws is between using a model as autocomplete and using it as a drafting tool inside a content-design system. Autocomplete is accepting the cheery-bot output because it is grammatical and ships it. Content design is encoding the voice and the situational requirements into a structured prompt, auditing the output and the existing copy against named failure modes, rewriting to fix failures rather than add polish, and documenting the patterns so the standard persists. The model is genuinely useful in the second mode, generating drafts fast that you then steer and verify, and genuinely dangerous in the first, flooding the product with fluent, friendly, situationally-wrong copy that nobody edits because it reads fine.

The user never sees your prompt or your audit. They see "Your session expired, so we couldn't save your changes. Sign back in and we'll restore your draft," and they feel taken care of, and they recover. Or they see "Oops! Something went wrong," and they feel abandoned, and they churn. The microcopy is small and it is the entire texture of the product experience, and whether it helps or abandons the user comes down to whether a content designer supplied the understanding the model lacks. That is the job, and the pattern library is how you make it scale.

There is a final point worth making about the hardest failure to catch. The most dangerous AI error message is not the one that is obviously cheery and vague; it is the one that is grammatical, on-brand, friendly, and recommends a recovery that does not actually resolve the cause. It passes every surface check - tone, voice, the presence of a recovery - so a reviewer skimming for fluency approves it, and only a content designer who asks "does this recovery actually fix this specific cause" catches it. That is why the recovery-path check is its own explicit step, independent of how good the copy reads, because polish is exactly what hides the situational failure underneath.

Putting It to Work This Week

This week, write the structured voice-and-tone prompt for your product, with concrete voice rules and examples, not adjectives. Use it to draft the three patterns - empty state, error, success - for one real surface, and check each draft against the four failure modes. Then pull twenty existing strings, run the voice-and-tone audit, lay them out together to see the drift, and rewrite the worst five to fix named failures, not to add warmth. Commit the audit and a microcopy pattern library to your design-system docs. The next person who writes a string, human or model, will have a standard to meet, and your product will start speaking with one voice that actually helps.

Key Takeaways

• AI-written UX copy fails in four predictable ways: cheery-bot tone (context-blind friendliness), generic verbs (weak all-purpose words that carry no information), missing recovery paths (problems described with no working fix), and missing accessible alternatives (copy assuming sight and a pointer). All four are failures of understanding the situation, not of grammar.
• The model writes fluent English every time - fluency is its high-frequency strength - but situational appropriateness (right tone, exact verb, working recovery, accessible phrasing) is the low-frequency, high-stakes part it cannot reliably supply.
• A structured voice-and-tone prompt anchors the model: concrete voice rules with examples, the specific surface and situation, the required elements, and hard constraints. It moves output from autocomplete to a draft worth editing, but does not eliminate the need for the audit.
• The three microcopy patterns have different requirements: empty states orient and encourage, error messages follow cause-consequence-recovery-reassurance, and success confirmations confirm quietly without over-celebrating routine actions.
• The brand-voice audit checks twenty existing strings against the voice definition and the four failure modes, laid out together because voice drift is most visible in aggregate; rewrite the worst five to fix named failures, not to add polish - plain and correct beats warm and vague.
• The artifact is a voice-and-tone audit plus a microcopy pattern library committed to the design-system docs; the pattern library is the institutional memory that keeps the product's voice consistent as people and tools change, the copy analog of a brand-anchor reference set.