# Microcopy with AI: What to Hand to a Model and What to Keep

> AI can generate microcopy variants and check length, but it fails on audience, tone and accessibility. What to delegate to a model and what to review by hand.

*Tags: ai, microcopy, ux-writing, accessibility*

---


> [!info] Quick Definition
> **Microcopy** is the very short text in an interface: button labels, hints, error messages, placeholders. **Microcopy with AI** is the use of language models to generate and adjust that text under one clear rule: the model proposes variants and a person decides, especially on tone, audience and accessibility.


## What is microcopy, and why is it hard to delegate?

Nielsen Norman Group defines microcopy as copy shorter than three sentences and gives it three goals: inform, influence a choice, and support interaction with the interface. One piece of text can serve one or several of them, and it helps to know which before writing it.

For informational microcopy, NN/g adds three priorities, in order: **clarity** first, then **concision**, then **character** (tone, humor, whatever humanizes the text), as long as character does not get in the way of the other two. That order is useful when reviewing what a model proposes: a charming but confusing text fails the first test.

Delegating it is hard because the right words depend on the product, on who uses it and on the moment. A model does not see the screen on the phone of someone in a hurry. For the general writing workflow with AI (context, glossary, per-screen prompts), see [[ux-writing-with-ai|UX writing with AI]]; this page focuses on what to delegate and what not to.

## What does AI do well?

LogRocket (January 2026) lists uses where AI speeds things up with little risk:

- **Brainstorming**: it generates options for the same state (their example runs from "In progress" to "Getting it done") that the writer then refines. These are starting points, not final copy.
- **Editing**: adjusting tone and flagging text that exceeds a character limit.
- **A first cultural pass**: flagging possible translation or cultural issues before testing with real users.

One more use, from common sense rather than from LogRocket: asking for a list of vocabulary inconsistencies (the same action called "Delete" on one screen and "Remove" on another) across text that already exists. Check the list, because the model can invent differences or miss others.

In every case the model works on text that already makes sense. The underlying judgment stays human.

## Where does it fail?

The same LogRocket article documents recurring failures:

- **Cultural bias**: when asked to tailor copy for users in Nigeria, the author reports that the model defaulted to Nigerian Pidgin, even though not everyone speaks it and many expect formal, plain English in professional products.
- **Wrong tone**: a bank used playful language that did not suit an older user who expected a professional tone. The author takes the case from a LinkedIn post.
- **Accessibility**: it defaults to patterns such as "Click here," vague labels such as "Submit" or "Continue," and errors like "Oops... Something went wrong!" that leave users with no next step.
- **Overcorrection**: if you ask it to adapt text to an audience, it can fall into stereotypes. In the author's example, ChatGPT flagged the word "smash" as risky for young Nigerians, but testing with local users showed it was clear in context. She treats the flag as a lead to investigate, not a verdict.

These failures share one trait: they are plausible. A text that sounds right passes a quick read even when it does not serve the person reading it. That is why review has to be deliberate.

## Which accessibility criteria does microcopy touch?

Four WCAG 2.2 success criteria depend directly on the words you write:

| Criterion | Level | What it requires | What it means for the text |
|---|---|---|---|
| 3.3.1 Error Identification | A | If an input error is detected, the field is identified and the error is described in text | Red color is not enough; the message must say which field and what happened |
| 3.3.3 Error Suggestion | AA | If the correction is known, it is suggested | "Invalid date" is worse than "Use the format DD/MM/YYYY" |
| 2.4.4 Link Purpose (In Context) | A | The purpose of each link can be determined from its text or its context | A bare "See more" fails if no context clarifies it |
| 2.5.3 Label in Name | A | The accessible name includes the visible text | If the button says "Pay," its accessible name cannot be "Complete transaction," or voice control will not activate it |

A model does not check these criteria on its own. Ask it to keep them in mind, but verify the result yourself.

## How do you prompt for and review generated microcopy?

To ask for it, give the model what it cannot guess: which screen it is, what the person just did, what action comes next, the character limit and the product's official terms. Ask for three variants with a one-sentence rationale each, not a single answer.

To review it, use this list before approving:

1. **Does it say what happened and what to do?** In an error, the first sentence explains the problem and the second gives the way out.
2. **Does it make sense on its own?** A screen reader can list links out of context. "See more" does not say more of what.
3. **Is it clear before it is charming?** Apply the order clarity, concision, character.
4. **Does the accessible name match the visible text?** Check with an accessibility tool or with voice control.
5. **Is it true inside the product?** If it promises a deadline or a result, confirm with the team that the system delivers it.
6. **Has someone from the real audience seen it?** If you have research sessions, use that reference, not the model's.

## Example

Illustrative example: a payment form shows a "Process" button. You ask a model for variants of up to 24 characters and it returns "Process payment," "Confirm purchase" and "Pay now." The team rejects all three in review: "Pay now" suggests an immediate charge, when the charge actually happens two days later. They keep "Confirm purchase" and add a line underneath saying when the charge occurs. What the screen promises was a human decision.

## Common mistakes

- Giving the model a tone but not the audience or real examples.
- Accepting generic labels ("Submit," "OK," "Accept") because they sound normal.
- Reviewing only length and not meaning.
- Forgetting that a button or link without context is a problem for screen reader users.
- Using the same prompt for every audience.
- Publishing promises (deadlines, prices, results) the model wrote without verifying them.

## When should you not delegate it?

In legal, safety or billing text, and in error messages about personal data or money that the user must understand without ambiguity. There the model can propose options, but the final text is approved by the person responsible for the product and, where relevant, legal.

## Sources

- [Nielsen Norman Group, The 3 I's of Microcopy: Inform, Influence, and Interact (August 2025)](https://www.nngroup.com/articles/3-is-of-microcopy/)
- [Nielsen Norman Group, The 3 C's of Informational Microcopy (March 2026)](https://www.nngroup.com/articles/3-cs-microcopy/)
- [LogRocket, AI is fast at UX copy: that's exactly the problem (January 2026)](https://blog.logrocket.com/ux-design/ai-ux-writing-where-it-works-and-fails/)
- [W3C, Understanding SC 3.3.1: Error Identification](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html)
- [W3C, Understanding SC 3.3.3: Error Suggestion](https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html)
- [W3C, Understanding SC 2.4.4: Link Purpose (In Context)](https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html)
- [W3C, Understanding SC 2.5.3: Label in Name](https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html)


---

Source: https://www.fernandoux.com/en/wiki/ai/microcopy-with-ai/