UX Copy Prompt for Buttons and Errors

What this prompt does

A UX copy prompt writes the strings a screen needs but doesn't have yet: the button label, the heading on an empty list, the line that appears when something fails. It takes a screen and the user's state at that moment and returns options that fit the space they have to fit into, in the voice the rest of the product already uses.

The character limit is what makes this different from ordinary copywriting. A tagline can run long and still work. A button can't. Ask a model for button text and it hands you "Continue to your personalised dashboard" for a control that has room for eighteen characters, and the line reads well right up until a designer has to set it.

So the prompt below counts. Every option comes back with its length, anything over budget is replaced rather than flagged, and the unknowns become questions instead of invented facts about a product the model has never seen.

Three strings, three options each, is a normal ask. You're picking, not accepting.

The prompt

Write the interface copy for the screen described below. Follow every rule.

**Screen or component:** [WHAT IT IS — e.g. "the empty state on the saved-jobs list", "the confirm dialog for deleting a workspace"]
**Product, in one sentence:** [WHAT IT DOES AND FOR WHOM]
**Who is looking at it:** [THE ROLE, and whether this is their first time on this screen or their fiftieth]
**What just happened:** [THE ACTION OR STATE THAT PUT THEM HERE]
**What they should do next:** [THE ONE ACTION, or "nothing, this is informational"]
**Strings needed, with limits:** [ONE PER LINE — e.g. "heading, 40 characters; body, 120; primary button, 18; secondary button, 18"]
**Voice:** [THREE ADJECTIVES, or paste two real lines from the product and say "match this"]
**Words we never use:** [BANNED TERMS, COMPETITOR NAMES, LEGAL NO-GOES, or "none"]

Return a markdown table: one row per string slot, three options per row, and a final column giving the character count of the longest option in that row. Below the table, add a short "Why" list — one line per slot naming what the three options actually differ on, so I can choose instead of guess. Close with "Open questions" for anything you had to guess at.

Rules for length:

- Count the characters. Any option over its stated limit is a failed option: replace it, do not return it with an apology. The count you print must be the real one.
- If a limit makes the required meaning impossible, say so in Open questions and give me the shortest honest version plus the count it needs.

Rules for buttons:

- A button says what happens when it is pressed. Verb first, in the reader's words, agreeing with the heading above it.
- Banned button text: Submit, OK, Yes, No, Click here, Learn more, Get started (unless nothing is starting).
- On a destructive confirmation, the confirm button names the destruction and its scale ("Delete 3 drafts"), and the way out is stated plainly ("Keep them"), never as a bare Cancel.

Rules for errors:

- Three parts, one or two sentences: what happened, why if the brief tells you why, and what to do next. If the brief does not say how to recover, write the line and mark it [needs: recovery step]. Do not invent the fix.
- Never blame the reader. No "you failed to", no "invalid", no "illegal entry".
- Never expose internals: no status codes, exception names, database field names, or the word null.
- No exclamation marks. No Oops, Uh oh, Whoops, or Sorry about that. No emoji unless the voice field asks for them.

Rules for empty states:

- Three different screens share that name, and they need different copy: nothing created yet, a search or filter that matched nothing, and a failure to load. If my brief does not make clear which one this is, ask before writing.
- Nothing-yet teaches one thing and offers one action. Nothing-matched repeats what was searched and offers a way back. Failed-to-load says it is temporary and offers a retry.

Rules for everything:

- Sentence case for every string, buttons included. No Title Case, no ALL CAPS.
- Use only the product facts I gave you. Do not invent feature names, plan tiers, prices, timeframes, quantities, support hours, or keyboard shortcuts.
- Write for someone mid-task who is not reading carefully. If a sentence needs a second pass to parse, cut it.
- Where two of my inputs contradict each other, write neither version and raise it in Open questions.

How to use it

1. Give the limits in characters, not "short". The single input that changes the output most is the number. "Short" gets you a range from four words to fourteen; "18 characters" gets you something that fits the control you already drew.
2. Describe the moment, not just the screen. "The empty saved-jobs list" and "the empty saved-jobs list, seen by someone who has been using the app for four months and just cleared it" want different copy. The second is the one that produces a line worth shipping.
3. Paste two real strings under Voice. Adjectives drift. Two existing lines from the product pin the register far better than "friendly, clear, human", and they stop the model reaching for a house style that isn't yours.
4. Read the Open questions before the table. That's where the brief was thin. A model that asks "does the retry re-upload the original photo or ask them to take a new one?" has found a product decision nobody made, and no wording choice settles it.
5. Set the winning option in the real interface before you sign off. A line that reads fine in a table can be two characters too wide at the largest supported text size, in German, on the smallest phone you support.

The button rules aren't preference. The GOV.UK Design System's button component instructs teams to "write button text in sentence case, describing the action it performs", and the examples it gives turn on a distinction most product teams never write down: use "Continue" when the service does not save a user's information, and "Save and continue" when it does. Same control, same screen, and the right label depends on what the system quietly does behind it.

Error copy carries an accessibility obligation too, not just a tone one. WCAG 2.2 Success Criterion 3.3.3, Error Suggestion, is a Level AA requirement: "If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user." An error that states only what went wrong is a failed AA checkpoint, which is why the prompt splits every error into what happened and what to do next, and refuses to invent the second half when the brief doesn't supply it.

Example output (partial)

Screen: the upload-failed state in a field-inspection app for building surveyors. What just happened: a site photo failed to send; the surveyor is in a basement with no signal. Next action: none available until signal returns; the photo is already stored on the device.

Why. The heading options trade reassurance against explanation: A leads with the good news, B names the cause, C names only the state. Body A is the longest and the only one that says "nothing to redo", which is the sentence a surveyor holding a phone in a basement actually wants. The primary buttons all send them back to work rather than offering a retry, because the brief says no action is available. Secondary options differ on whether "pending" is a word this audience uses.

Open questions. (1) Does the app already show a pending-uploads count somewhere? If it does, the secondary button should match that label exactly rather than introducing a second name for the same thing. (2) What happens if the surveyor closes the app before signal returns — does the photo still send? The body copy promises it sends by itself, and that promise is only safe if the answer is yes.

Question 2 is the one that matters. Three of these options tell a surveyor their work is safe, and if the upload only resumes while the app is open, all three are lies written in a confident voice.

Variations

For a whole flow rather than one screen

"Here are the four screens in this flow, in order, with each one's strings and limits. Write them as a set: no heading may repeat a word from the previous screen's heading, and the button labels must read as a sequence, not four unrelated verbs."

To match an existing product voice at scale

"Before writing anything, read the 15 strings below from our current product and describe the voice in five specific rules — sentence length, contraction use, how we address the reader, what we never say. Then write the new strings against those rules, and flag any string where the rule and the character limit conflict."

For copy that has to survive translation

"Every option must stay under the limit with 35% expansion, since this ships in German and Finnish. Prefer short common verbs over idioms. Flag any option whose meaning depends on English word order or a pun."

Common pitfalls

• Don't ask for one option per slot. Three is the point: you learn what the trade-off is by seeing the alternatives, and a single option gets accepted purely because it's there.
• Don't paste the whole design brief in and hope. The prompt reads "what just happened" as the load-bearing input, and a two-page brief buries it in project context the copy doesn't need.
• Don't let a clever error message ship without checking where it appears. Nielsen Norman Group's error message guidelines put visibility before wording — display the message close to the error's source, since proximity is what links the words to the thing needing attention. Perfect copy in the wrong place still reads as no copy at all.
• Try instead: hand the table to whoever built the screen and ask which options are technically true. On the surveyor example above, that question kills at least one row.

ChatGPT is the fastest at producing genuinely different options rather than three rewrites of one idea. Claude holds the banned-word list and the sentence-case rule best over a long multi-screen run. Gemini drifts back into Title Case on buttons after the first table, so restate that rule if you're doing a whole flow. Character counts are unreliable from all three — they'll print a number that's off by two or three, so verify the ones near the limit yourself rather than trusting the last column.

Who uses this prompt

• Designers: filling the empty text layers in a screen that's otherwise finished, which is the part that stalls a handoff. More in prompts for designers.
• Copywriters: brought onto a product late, with a component library and no voice documentation. See prompts for copywriters.
• Product managers: writing the first draft of an error state so engineering isn't inventing one at build time. The rest are in prompts for product managers.

The strings this prompt writes are the ones nobody is assigned. A button label gets typed by whoever is in the file at 5pm, and it stays there for years.