30 AI Prompts for UX Writing and Microcopy

TL;DR: These are 30 UX writing prompts for the microcopy that actually ships: buttons, error messages, empty states, tooltips, confirmation dialogs, and system notifications. Each prompt names the component's job and its character ceiling, because a model asked for "a good button label" with no container in mind writes copy that never fits where it has to live.

What Makes an AI Prompt Actually Useful for UX Writing?

Most AI copywriting content assumes one job: persuade someone across a page they are already reading, an ad, a landing page, an email. UX writing is a different job. A button label, a validation error, an empty state, and a permission dialog each live inside one specific component, with its own length ceiling and its own reason to exist. A button gets someone to act. An error message gets them unstuck. An empty state gets them started. A tooltip answers one question without demanding attention. Ask a model for "better microcopy" with no container in mind and it defaults to whichever tone it associates with UI text in general, usually a little too cheerful, and a length that may not survive the space it has to live in.

If you need persuasive copy for a page someone reads once, our guide to AI prompts for landing page copy covers that job directly. This one is for the copy embedded in the product itself, the part a designer, a PM, or whoever is left holding the ticket ends up writing by hand. Our prompts for product managers cover the spec side of that same handoff, PRDs and user stories, if the microcopy in your ticket still needs a decision made above it first.

The 30 prompts below are organized by component, not by industry or brand voice, because the component is what actually constrains the writing. Fill in the job, the constraint, and the voice you already use, and the draft that comes back is closer to something you can paste in, not something you have to rewrite from scratch.

Why Do Character Budgets Change What You Should Even Ask For?

A prompt that does not name the container produces copy for no container at all. A button label has to read at a glance, often on a small screen, competing with an icon: length matters in a way a paragraph never will. A confirmation dialog has to make sense inside the two or three lines a modal shows before anyone starts scrolling a popup, which nobody does. An error message has to fit next to the field it is attached to, not spill into a second line that pushes the rest of the form down.

None of that is a rule you hand a model once and forget; it is a constraint you state every time, because components differ and the model cannot see your screen. Two techniques help more than any wording trick: feed the model a few of your product's existing button labels or error messages as few-shot examples before asking for a new one, since matching an established voice beats describing it in adjectives, and ask for the character count alongside every draft, so you can screen for fit before you paste anything in.

What Are the Best AI Prompts for Button and CTA Labels?

A button label has one job: tell someone exactly what happens when they press it. "Submit," "OK," and "Continue" all pass a syntax check and fail the actual job, because none of them say what is about to happen. "Delete project," "Send invite," and "Save and continue" each commit to a specific action a person can decide about before they click. The five prompts below ask for that specificity directly, plus a same-meaning variant labeled with a different verb, usually the fastest way to catch a label that is technically fine and practically vague.

1. Primary action button, specific verb

Screen or flow: [where this button lives, e.g. "checkout, final step"]
Action the button triggers: [exact action, not a category, e.g. "charges the saved card and confirms the order"]
Existing labels nearby it must not be confused with: [list]
Write 5 button label options, 1-4 words each. For each, state whether the label alone, with no surrounding context, makes the action clear to someone seeing only the button.

2. Destructive action button that needs a real pause

Action: [e.g. "permanently deletes this workspace and every project in it"]
Is this action reversible: [yes/no, and how if yes]
Write a button label that names the specific thing being destroyed, not a generic "Delete." Also write the one sentence of body copy that goes above it inside a confirmation dialog, stating what is lost and whether it can be undone.

3. Secondary or low-commitment action

Primary action on this screen: [what the main button does]
This button's action: [the lower-commitment alternative, e.g. "save as draft instead of publishing"]
Write a label that reads as clearly lower-commitment than the primary button next to it, without using the word "skip" unless skipping this step is genuinely free of consequence.

4. Same button, five verb options for a test

Action: [what happens on click]
Audience: [who sees this button]
Write 5 single-verb-led label variants for the same action (for example "Start," "Try," "Get," "Build," "Create"), each under [N] characters. Flag any variant that changes what the user expects to happen next, not just the tone.

5. Icon-only button, accessible name

Icon: [describe it, e.g. "three vertical dots"]
Action it triggers: [exact action]
Write the visible tooltip text, if any, and the accessible name a screen reader announces, separately. They do not have to be the same string, but both must be understandable with no icon visible.

What Are the Best AI Prompts for Error Messages?

Error messages are the highest-value microcopy on any product, because they appear exactly when someone is already stuck, and the easiest category for a model to get wrong in a way that still looks fine on a quick read. Ask for "a friendly error message" and most models return an apology with no information in it: something like "Oops! Something went wrong. Please try again." That sentence says nothing about what happened, why, or what to try instead, and it repeats itself identically for a wrong password, an expired session, and a server outage, three different problems with three different fixes.

The UK government's own design system publishes tested, publicly documented guidance for this exact component, and states plainly that generic messages like "An error occurred", "Answer the question", and "This field is required" are not helpful to everyone, because they do not make sense out of context. Its own comparison is worth prompting for directly: "Enter your first name" reads clearer than "First name must have an entry", an instruction instead of a diagnosis. It is also explicit about what an error message should never do: do not use one to tell someone they lack permission for something the interface could have prevented earlier; that belongs on its own page, not a form-field error.

The fix is a prompt that asks for three things every time: what happened, why it happened when the cause is knowable and safe to state, and the one action that gets the person unstuck. None of the six prompts below ask for a friendly tone. They ask for the recovery path.

6. Validation error, specific and instructive

Field: [field name]
What was entered: [the actual value or type of value, e.g. "an email with no @"]
What is actually required: [the real constraint]
Write an error message that states what is wrong and what to enter instead, in one sentence. Do not use "invalid," "error," or "please try again" without saying what to try.

7. Failed action, not a failed field

Action attempted: [e.g. "publish this page"]
What blocked it: [the real cause, e.g. "two required fields are still empty"]
Is this the user's fault, a system limit, or a third-party failure: [state which]
Write the error message and, separately, the one-sentence recovery instruction. If the cause is a system limit or a third-party failure, the message must not imply the user did something wrong.

8. Expired session or authentication error

What expired: [session, token, invite link, etc.]
How long it has been, if known: [state it]
What happens to unsaved work, if anything: [state it]
Write a message that says what expired and what to do next in one sentence, plus a second sentence only if there is a real risk of lost work.

9. Rate limit or plan-limit error

Limit hit: [e.g. "5 prompt enhancements today," "50 saved prompts"]
When it resets, if it does: [state it]
The two next steps: [e.g. "wait until reset" and "upgrade"]
Write the message and both next-step options as separate short lines, not folded into one sentence. Do not use the word "sorry."

10. System error that is not the user's fault

What broke: [the real failure in plain terms, e.g. "the server did not respond in time"]
Is retrying likely to work: [yes/no]
Where to check status, if anywhere: [link or none]
Write a message that names the problem as the system's, not the user's, states whether retrying is worth trying, and gives one thing to do if it is not.

11. Error summary at the top of a long form

Number of errors: [count]
Fields affected: [list]
Write the summary heading and the list of links to each broken field. Each link must name the specific problem, not just the field name, so the summary alone tells someone what to fix without scrolling to find out.

What Are the Best AI Prompts for Empty States?

An empty state is the only screen most products show before anyone has done anything, which makes it a strange place to write copy that assumes familiarity. The two failure modes are equally unhelpful: a flat "No items found" that reads like an error when nothing is actually wrong, and a caption so generic it could belong to any product's empty list. The four prompts below separate empty states by why they are empty, first use, filtered to nothing, or cleared by the user, because each needs a different next action, not the same illustration and the same sentence.

12. First-use empty state, nothing created yet

Object type: [e.g. "prompts," "projects," "contacts"]
The one action that creates the first one: [button or link this points to]
Write a headline, under [N] words, and one sentence of body copy that names the specific first action, not a generic "get started." No filler about how great the feature is.

13. Filtered-to-zero empty state

What is being filtered: [object type]
Filters currently applied: [list, or "unknown" if dynamic]
Write copy that makes clear the list is not actually empty, the filter combination just matched nothing, and includes an explicit action to clear or adjust the filter.

14. Cleared or completed empty state, a good outcome

What was cleared: [e.g. "inbox," "task list," "review queue"]
Is reaching zero here genuinely a good thing: [yes, describe why]
Write copy that reads as a real milestone, not a generic empty-list template, without overselling a routine task as an achievement.

15. Empty state after a failed search

What was searched: [object type]
Is echoing the search term back useful here: [yes/no]
Write copy that confirms what was searched, states nothing matched, and suggests one specific next step, broaden the term, check spelling, or browse instead of search, not just "try again."

What Are the Best AI Prompts for Tooltips and Inline Help?

A tooltip's job is to answer one question someone might have without demanding they stop and read a help article, which only works if the tooltip stays optional. If the information inside it changes whether someone can complete the task safely or correctly, it does not belong behind a hover or a tap; put it in the interface itself. The four prompts below write to that limit deliberately: one sentence, one idea, and a check for whether the feature still works if the tooltip is never opened.

16. Field-level tooltip, one constraint

Field: [name]
The one thing someone might not know about it: [constraint, format, or consequence]
Write one sentence, under [N] characters, that states the constraint plainly. State whether the field would still be usable by someone who never opens this tooltip.

17. Feature-discovery tooltip, first exposure only

Feature: [name]
What it does in one clause: [not a feature list, the actual benefit]
Write a one-sentence tooltip for someone seeing this feature for the first time, plus a note on when it should stop appearing, after first dismissal, after first use, or never automatically.

18. Disabled-state tooltip, why can't I click this

Disabled control: [name]
Exact reason it is disabled right now: [state the real condition, e.g. "no payment method on file"]
Write the tooltip shown on hover over the disabled control, naming the specific blocking condition and, if possible, a link or action that resolves it.

19. Inline help text under a field, not a tooltip

Field: [name]
Information that should always be visible, not hidden behind a hover: [state it and why]
Write the persistent helper text below the field, under [N] characters, and confirm in one line why this belongs on the page instead of inside a hover tooltip.

What Are the Best AI Prompts for Confirmation and Permission Dialogs?

A confirmation dialog exists to slow someone down for exactly as long as the action deserves, and no longer. The most common failure is not a bad sentence, it is the wrong dialog for the stakes: a routine save wrapped in a modal nobody needed, or a genuinely destructive action confirmed with the same generic "Are you sure?" used everywhere else, which trains people to click through without reading. A permission dialog carries a second job on top of that: it has to explain, in terms a non-technical person actually understands, what access is being requested and why.

20. Destructive-action confirmation

Action: [e.g. "delete this account and all its data"]
Reversible: [yes/no, and how if yes]
What is actually lost if confirmed: [be specific: files, history, billing records]
Write the dialog headline, one sentence of body copy naming what is lost, and two button labels, confirm and cancel, that each name the action, not "Yes" and "No."

21. Routine-save confirmation, should this even be a modal

Action: [e.g. "save these settings"]
Is there real risk in getting this wrong: [state it honestly]
First, answer whether this action needs a confirmation dialog at all. If yes, write the minimal version. If no, write the alternative, a toast, an undo option, or no dialog, instead.

22. Permission request dialog, non-technical explanation

Permission requested: [e.g. "access your calendar"]
What it is used for, specifically: [not "to improve your experience," the actual feature it enables]
What happens if permission is denied: [state it]
Write the dialog in plain language a non-technical person understands on first read, naming the specific feature this unlocks and what still works if they say no.

23. Bulk-action confirmation, affects more than one item

Action: [e.g. "archive"]
Scope of items affected: [how this is communicated, e.g. "47 selected" or "all items matching this filter"]
Write a confirmation that states the exact scope being affected, not just the action name, since bulk actions are the most common place people confirm something bigger than they meant to.

What Are the Best AI Prompts for Notifications and System Messages?

A toast or system notification has less room than almost any other component and the shortest attention span to work with: most disappear on their own, on a timer the user did not set. That makes the content, not the styling, the only thing standing between "something happened" and someone actually knowing what to do about it. The three prompts below write to that constraint: state the event, state whether action is needed, and skip anything that is not one or the other.

24. Success toast, action-confirming and auto-dismissing

Action completed: [e.g. "invoice sent"]
Is there a follow-up action worth surfacing here, undo, view, share: [state it or "none"]
Write a one-line toast, under [N] characters, naming what happened. Add a single action link only if there is a real one, not a generic "View."

25. Persistent system banner that does not auto-dismiss

Condition causing this: [e.g. "payment failed," "storage almost full"]
Does this block any functionality right now: [state exactly what does and does not still work]
Write the banner text and its one action button, and confirm the message states what is actually blocked, not just that something is wrong.

26. Background-process notification, finished while away

Process: [e.g. "export," "import," "bulk edit"]
Outcome: [success, partial success, or failure, and why if failure]
Write the notification for someone returning to find this already finished, naming the outcome specifically enough that they do not have to click in to find out whether it worked.

How Do You Prompt for Accessible Microcopy Without Overclaiming Compliance?

Two accessibility requirements are genuinely about wording, not markup, and a prompt can address both directly. The first is link and button text that makes sense with no surrounding context. MDN's own accessibility guidance is blunt about the common failure: "Don't just use "Click here" for your labels, as screen reader users sometimes get up a list of buttons and form controls." Its own example is worth borrowing as a check, not just a rule: "Find out more about whales" stands on its own; "click here" sitting in the same sentence does not.

The second is what happens when something needs to interrupt without stealing keyboard focus, the exact job an error or status announcement does. The WAI-ARIA Authoring Practices Guide defines the pattern directly: an alert "displays a brief, important message in a way that attracts the user's attention without interrupting the user's task." The same guidance calls it "crucial they do not affect keyboard focus." That is a structural requirement, the alert role or a live region, not a wording one, and no prompt fixes markup. What a prompt can do is write text short enough to survive being announced once, with no visual context to lean on.

Neither prompt below claims the result meets any particular accessibility conformance level on its own. Wording is one input into an accessible component; the markup, the live region, and a real screen-reader test are the other three, and none come from a chat window. Verify the output yourself before it ships, the same discipline our piece on red-teaming your own prompt argues for everywhere else.

27. Standalone link text inside body copy

Surrounding sentence: [the sentence this link sits inside]
Destination: [what the link goes to]
Write link text that makes sense read on its own, outside the sentence, not "click here" or "read more" with no noun attached. Confirm in one line that the link text alone, with no surrounding sentence, states where it goes.

28. Status message that must interrupt without stealing focus

Event: [e.g. "autosave completed," "connection lost," "form submitted"]
Does this need immediate announcement or can it wait until the next natural pause: [state which]
Write the message assuming it will be read aloud on its own by a screen reader, with no visual styling to lean on. One sentence, stating what happened and whether anything is needed from the user.

How Do You Prompt for Microcopy That Still Fits After Translation?

English microcopy is usually the shortest version of a message that will ever exist, which is the opposite of a safe assumption to design around. Guidelines published by IBM, cited in the W3C's internationalization documentation, give average expansion rates by source length, and the pattern runs backwards from what most people expect: the shortest strings expand the most, not the least.

A two-word button label at the top of that table can nearly triple in some target languages; a full paragraph, at the bottom, barely grows. Some languages compound the problem structurally rather than just running longer: the same source gives the English "Input processing features" becoming "Eingabeverarbeitungsfunktionen" in German, one unbroken word with no natural place to wrap inside a narrow tab or button.

No prompt fixes this, because the expansion is a property of the target language, not a defect in the English draft. What a prompt can do is ask for the shortest version that still states the action, flag any draft under roughly 20 characters as a translation-length risk, and leave the layout question, reflow or silent truncation, to design.

29. Length-safe button or label draft

Action: [what the label does]
Target languages this ships in, if known: [list, or "unknown, design for German and Finnish as a stress test"]
Write 3 label options, under [N] characters each, and flag any option under 12 characters as a likely translation-expansion risk before it ships.

30. Compound-risk label for languages that fuse words

Phrase: [the English microcopy]
Write the phrase as short as it can be while staying literal, no idioms, no wordplay, since idiomatic English is the hardest source text to translate accurately. Flag whether the phrase describes one concept or two, since a two-concept phrase is more likely to become one long compound word in German, Finnish, or Dutch.

How Prompt Architects Fits This UX Writing Workflow

All 30 prompts above run in whatever AI tool you already use, ChatGPT, Claude, or Gemini, no extension required for a first draft. Prompt Architects' own FAQ page states the free plan runs 5 architected prompt enhancements a day, forever, enough to test the error-message and empty-state prompts above before deciding whether saving any of it is worth paying for.

What the paid plans add is what makes reusing this structure across dozens of components sustainable: a prompt library to save each of these 30 with your product's field names already filled in, Refine and Shorten Mode to tighten a draft that has landed close but not quite right, and, on Pro and above, a Tone Selector applying one consistent voice across a batch instead of re-explaining it every prompt. If your product already has a documented voice, our guide to building a brand-voice context covers storing it once instead of retyping it per component. For a whole component's strings at once, ask for structured output instead of prose so it drops straight into a strings file; our guide to JSON prompts covers the syntax.

If you are the one person writing every button, error, and tooltip by hand, that is the gap this closes: not the first draft, the fiftieth.

Save these prompts to your library, free to start, works inside ChatGPT, Claude, and Gemini →