The UX writing prompts below draft and review the small text that carries an interface: button labels, form hints, error messages, empty states, confirmations and onboarding. Each one asks for the screen context and a length limit, and returns options with the reasoning, so you pick the copy instead of accepting the first draft.
How to use these prompts
Each prompt is ready to copy into ChatGPT, Claude or Gemini. Replace the blanks in double braces, or keep the default after the colon: {{product:a team task manager}} means "a team task manager" unless you change it.
What makes the output usable:
- Describe the moment. Who the user is, what they were trying to do, and what happens next. "Payment failed" copy depends on whether the card was declined or your server timed out.
- State your voice rules. Paste your style guide's key rules or two examples of copy you like. Without them, models default to cheerful filler.
- Set a length limit. Interface text has to fit a button, a toast or a mobile screen.
- Ask for options and pick. Three options with trade-offs beat one confident answer.
If your product ships in several languages, write source copy that translates well, and see the translation prompts for the localization side.
Which prompts help with microcopy?
1. Button and link labels
Labels should say what happens when you click. "Submit" and "OK" rarely do.
Write button labels for this action in {{product:a team task manager}}.
Screen: {{screen}}
What the button does: {{action}}
What happens after the click: {{result}}
Max length: {{max_chars:20}} characters
Give 5 options. Each should start with a verb and describe the outcome.
For each, note one trade-off (clarity, length, tone). Mark your top pick and
say why. Avoid "Submit", "OK" and "Click here".
2. Form labels, hints and placeholders
For a form where users keep entering the wrong thing.
Write the text for this form in {{product:a team task manager}}.
Fields and what we need from each:
{{fields}}
For each field give: a label (short, a noun or question), hint text only if
the user needs it to answer correctly, and whether a placeholder is useful.
Don't put essential instructions in placeholders, since they disappear when
the user types. Note any field we might not need to ask for.
3. Rewrite copy to our voice and length
For existing copy that is too long, too formal or too cute.
Rewrite this interface text to match our voice and fit {{max_chars:80}}
characters.
Voice rules: {{voice:clear, calm, plain words, no exclamation marks, no jokes in errors}}
Original:
{{copy}}
Give 3 versions, each with its character count. Keep the meaning and any
legal or factual details exactly. Tell me if something important had to go
to fit the limit.
4. Confirmation dialog for a destructive action
Deleting, cancelling or overwriting deserves copy that makes the stakes clear.
Write a confirmation dialog for this action: {{action:deleting a project}}.
What is lost: {{consequence:all tasks, files and comments in the project}}
Can it be undone: {{undo:no}}
Give: a title that names the action and object, one or two sentences on the
consequence, a confirm button that repeats the action ("Delete project", not
"Yes"), and a cancel button. Offer one alternative version with a safer
option if one exists, such as archive instead of delete.
Which prompts help with error messages?
5. Error message from a technical cause
Paste what the logs say. The model translates it into what the user needs to know.
Write a user-facing error message for this situation in
{{product:a team task manager}}.
Technical cause: {{cause}}
What the user was doing: {{task}}
What the user can do about it: {{fix}}
Where it appears: {{placement:inline under the field}}
Rules: plain language, no error codes unless support needs them, say what
happened and what to do next, don't blame the user, no "Oops". Give 3
options under {{max_chars:120}} characters each.
6. Validation messages for one field
One message per failure type, the way the GOV.UK Design System recommends instead of a single "invalid" message.
Write validation messages for this form field.
Field label: {{label:Email address}}
Rules: {{rules:required, must contain @, max 254 characters}}
Write one message for each way the input can fail (empty, wrong format,
too long, and any others the rules imply). Use the field's label wording.
Use an instruction for an empty field ("Enter your email address"). For
other failures, use an instruction or a description, whichever reads more
naturally, and stay consistent. Avoid "invalid", "please" and "sorry".
7. Audit existing error messages
Paste the error strings from your codebase or your copy doc.
Review these error messages against established guidelines: visible near the
problem, plain language, specific about what went wrong, a clear fix, and a
non-blaming tone.
{{messages}}
Give a table: original message, problems found, rewritten message. Then list
any messages that seem to cover several different causes and should be
split. If a message lacks context to rewrite well, say what you need.
8. Outage or total failure page
When the whole service is down, the copy is all users have.
Write the text for a page shown when {{product:a team task manager}} is
unavailable because of {{cause:an outage on our side}}.
Include: a heading that says what's happening, one or two sentences on what
users can and can't do now, whether their data is safe ({{data_safe:yes}}),
where to check status ({{status_url:our status page}}), and an apology that
sounds human. Under 80 words. No jokes.
Which prompts help with empty states?
9. Empty states for one screen
Most screens have more than one empty state. Write them all at once.
Write empty state copy for the {{screen:Projects}} screen in
{{product:a team task manager}}.
Write separate versions for:
1. First use: the user has never added anything.
2. No results: a search or filter returned nothing.
3. Cleared: the user finished or deleted everything.
4. Still loading or failed to load (so we don't show "nothing here" when
that isn't true).
For each: a short heading, one sentence on what goes here or why it's
empty, and a button or link label for the next step.
10. No search results
The most common empty state, and the most common dead end.
Write the copy shown when a search in {{product:a team task manager}}
returns no results for the user's query.
What users usually search for: {{search_targets:tasks, projects, people}}
Things we can offer: {{options:clear filters, search all workspaces, create a task with this name}}
Show the query back to the user, suggest the likely fixes in order, and
give the actions as button or link labels. Under 40 words plus labels.
Which prompts help with onboarding and feedback?
11. Onboarding tooltips
For a short tour that people don't skip in two seconds.
Write a {{steps:3}}-step tooltip tour for new users of
{{feature:the board view}} in {{product:a team task manager}}.
The one thing users must learn: {{key_task}}
Each tooltip: a title under 5 words, body under 20 words, and button labels.
Focus on what the user can do, not on describing the interface. The last
step should prompt the first real action.
12. Success and toast messages
Short confirmations that tell users the action worked, and what changed.
Write toast messages for these actions in {{product:a team task manager}}:
{{actions:task created, task moved, file uploaded, invite sent}}
Each under {{max_chars:50}} characters. Say what happened in past tense,
include the object name if useful, and add an "Undo" or "View" action label
where it would help. No exclamation marks.
13. Notification copy
For push or in-app notifications that people act on instead of muting.
Write a {{channel:push notification}} for this event in
{{product:a team task manager}}: {{event}}
Give 3 options with a title under 40 characters and body under 90. Lead with
what matters to the recipient, name the person or item involved, and make
the next step clear. Flag if this event probably shouldn't trigger a
notification at all.
14. Terminology list for the product
Inconsistent words ("workspace", "team", "org") confuse users more than any single bad label.
Here is interface copy from several screens of {{product:a team task manager}}:
{{copy}}
Find terms used inconsistently for the same thing, and the same term used
for different things. Propose a terminology list: preferred term, terms to
avoid, and a one-line definition. Also flag jargon a new user might not
understand.
What do the guidelines say about error messages and empty states?
These prompts follow a few well-established sources:
- Nielsen Norman Group's error message guidelines group advice into visibility, communication and efficiency: show the error near its source, use plain language, suggest a fix, keep a non-judgmental tone, and keep the user's input. They also warn that "Presenting errors too early is a hostile pattern."
- The GOV.UK Design System's core rule: "explain what went wrong and how to fix it." It also lists words to avoid, such as "invalid", "please" and "sorry".
- WCAG 2.2 success criterion 3.3.3 Error Suggestion (Level AA) requires that when an input error is automatically detected and suggestions for correction are known, the suggestions are provided to the user, unless that would jeopardize security or the purpose of the content.
- For empty states, Nielsen Norman Group's empty state guidelines recommend communicating system status, giving learning cues and offering direct paths to key tasks, noting that "Totally empty states cause confusion about how and whether the system is working."
How do you review AI-written microcopy?
Put each option into the real screen before choosing. Copy that reads well in a list can be too long for a button or confusing next to the field it belongs to. Check it with a screen reader for errors and dialogs, and run anything on a critical path past users. For accessibility checks of the whole screen, see the accessibility prompts.
Keep your UX writing prompts handy
The error message and empty state prompts get reused on every feature. Save them with your product name and voice rules as defaults, or turn one into a skill for Claude Code or Codex with the SKILL.md generator.
Kipt keeps prompts like these as Markdown files in a private GitHub repo you own. {{product}} and {{max_chars}} stay as blanks you fill in, tags sort them by screen type, and ⌘K finds them.