UX Writing with AI: How to Write Interface Copy with a Model
AI can draft and review UX copy fast, but it needs a tone guide, a glossary and web writing rules. Here is how to work with it without losing clarity.
What can a language model do well?
A language model is useful for three UX writing tasks:
- Generating variants: ten ways to say “Save changes” in under 20 characters, so you can test which one is understood best.
- Reviewing: spotting long sentences, jargon or inconsistent tone across a full screen.
- Adapting: turning a technical error message into a clear one for someone with no programming background.
What it can’t do alone is know what the user needs at that moment, what legal said, or which word your product uses for “workspace.” You have to give it that information.
What rules should the text follow?
In its article on generated content inside products, Nielsen Norman Group argues that this content should follow the same web writing rules: be concise, be scannable, lead with what the user needs to know (the inverted pyramid) and use plain language. For the web it recommends aiming for a sixth- to eighth-grade reading level. In its study, participants complained about jargon in answers to entry-level questions and about answers that were too long. The article also reminds readers that people read only about 20% of the content on a page.
Those rules were written for AI answers inside a product, but they work just as well for buttons, notices and error messages drafted by a model: if a text is not clear at a glance, shorten it.
Those rules apply to the prompt too. If the model must write an error message, tell it that the first sentence should explain what happened and the second what the person can do. “Write a friendly error” is not enough.
NN/g also distinguishes three goals of microcopy: informing and educating the user (for example, a tooltip that explains an icon), influencing them to take an immediate action, such as a conversion, and interacting, meaning supporting use of the interface with button labels, feedback and system status. When you generate copy with AI, decide first which of the three each text serves. A message that informs shouldn’t sound like a marketing campaign. For more on what to delegate and what not to, read Microcopy with AI.
How do you work with a model without losing control?
Do the work in four steps:
- Prepare the context. A document with the brand tone, three or four real product texts you consider good, and a glossary of official terms.
- Write the prompt per screen. Include what the person sees, what they must do and the character limit. Ask for three variants with a short rationale.
- Read in context. Paste the variant into the real screen or a prototype and read it where it will appear. A 40-character button can look fine in a document and get cut off on a phone.
- Save what worked. If a variant wins in a test, add it to the examples in the context. The model then learns your voice over time, even though each session starts from zero.
To make the process repeatable, keep the context in a file in the project, not in a chat’s memory. The same goes for any system prompt you use for the brand. That approach is described in context engineering.
How do you review what the model proposes?
NN/g describes how it uses AI in its own editorial process and leaves a useful idea for UX writing: AI helps, but people remain responsible for editorial judgment. According to that article, AI is useful for fitting a text to a character limit or for flagging possible contradictions, and the editor checks every flag against the source. It also warns about a concrete risk: shortening a text with AI can drop nuance.
Applied to an interface, you can run this checklist before accepting a variant:
- Meaning: does it say the same as the original, without dropping a condition or a warning?
- Vocabulary: does it use the glossary terms?
- Space: does it fit the real component, including small screens and other languages? If the product is translated, see Localization and translation with AI.
- Promise: does it claim something the system really does?
- Tone: does it sound like the rest of the product?
If a variant fails any of these, ask the model to fix it by telling it which point failed, instead of asking it to “make it better.”
Example
Illustrative example: a transit app needs a message for when a payment card is declined. A first draft from the model reads: “We regret to inform you that your transaction could not be processed at this time.” The team asks for variants using the rules above and chooses: “Your card was declined. Check the number or use another card.” The text is shorter, says what happened and what to do. The reviewer confirms that “card” is the glossary term, not “payment method.”
Common mistakes
- Accepting the first draft without reading it inside the screen.
- Asking for “a friendly text” without saying what happened or what the user must do.
- Letting each screen use a different term for the same concept.
- Using the model for legal, safety or pricing text without specialist review.
- Judging quality by personal taste instead of task metrics or user testing.
- Generating messages that promise something the system can’t deliver; a model can write this with full confidence if you do not tell it what the system does.
When NOT to use it
When the text has legal or safety consequences, when the brand voice was refined by a writer over months, or when the team lacks the capacity to review what comes out. In those cases, the model can help prepare options, but the final wording should be human.