Microcopy is the invisible infrastructure of good UX. It's every button label, every form hint, every error message, every tooltip, every empty state. Nobody notices microcopy when it's good. Everyone notices when it's bad — because they get confused, frustrated, or stuck.
These prompts help you write the small text that makes big differences. They're organized by UI component — pick the one you need, fill in the brackets, paste it into any AI tool. Each prompt includes constraints that prevent the generic, robotic output that makes UIs feel inhuman.
Form field labels & validation messages
Bad form copy is the number one conversion killer on signup and checkout pages. Vague labels make users guess. Aggressive error messages make them leave. This prompt generates the full set of microcopy for any form — labels, placeholders, validation errors, and helper text that actually helps.
I'm designing a form for [describe the form — e.g., "user signup", "checkout", "account settings", "booking flow"].
Product: [product name + one sentence description]
Audience: [who's filling out this form — technical level, context]
For each of the following fields, write:
1. LABEL — clear, concise (2-4 words)
2. PLACEHOLDER — example text showing the expected format (not just "Enter your...")
3. HELPER TEXT — one sentence below the field explaining WHY we need this or HOW to format it
4. ERROR: EMPTY — what to show when the field is required but left blank
5. ERROR: INVALID — what to show when the format is wrong (be specific about what's wrong)
6. SUCCESS — optional inline confirmation when the input is valid (only where it adds value)
Fields: [list your form fields — e.g., "email, password, company name, team size"]
Rules:
- Never blame the user ("Invalid input" is blaming). Say what needs to change.
- Error messages must say what went wrong AND how to fix it.
- Keep every string under 60 characters.
- Placeholder text should look like real data, not instructions.
- Tone: [helpful/casual/professional/playful]The forms that convert best aren't clever — they're clear. If you're seeing drop-off on a form-heavy page, microcopy is almost always the fix. Run your page through the landing page analyzer to see where friction is hiding.
Button & CTA text across the UI
Not every button is a landing page CTA. Your app has dozens of buttons — save, delete, confirm, cancel, upgrade, share, export. Each one needs text that tells users exactly what will happen when they click. This prompt covers the full range of button and CTA copy, not just hero sections.
I need button and action text for a [type of application — e.g., "project management SaaS", "e-commerce checkout", "mobile fitness app"].
For each of the following actions, write:
1. PRIMARY BUTTON TEXT (2-5 words, action-oriented)
2. SECONDARY OPTION text if applicable (e.g., "Cancel", "Go back", "Skip for now")
3. CONFIRMATION TEXT — what the user sees after clicking (toast, banner, or inline confirmation)
Actions:
[list 5-8 actions — e.g., "save changes, delete project, invite team member, upgrade plan, export report, cancel subscription, connect integration, publish draft"]
Rules:
- Use verbs that describe the OUTCOME, not the action. "Save" is fine. "Submit" is not — submit what?
- Destructive actions (delete, cancel, remove) need a confirmation step. Write the confirmation dialog copy too: headline, body text, confirm button, cancel button.
- Every button should answer: "What happens when I click this?"
- Match the weight of the action to the weight of the language. "Delete everything" should feel heavier than "Remove tag."
- No generic "OK" or "Submit" buttons. Every button gets a real label.
- Tone: [match your product's voice]The difference between a button that says "Submit" and one that says "Send invitation" is the difference between a confused click and a confident one. Our CTA analysis across thousands of pages shows specific button text consistently outperforms generic labels.
Empty states & zero-data screens
Empty states are one of the most neglected parts of any UI. A blank screen with "No data yet" tells users nothing — not what the feature does, not how to get started, not why they should care. Good empty states are onboarding moments in disguise.
I need empty state copy for my [type of application].
For each of the following empty screens, write:
1. HEADLINE (5-10 words) — tell the user what this area WILL show once they take action
2. BODY (1-2 sentences) — briefly explain the value of this feature and what it looks like when populated
3. CTA BUTTON — the specific action to populate this screen (not "Get Started")
4. OPTIONAL ILLUSTRATION SUGGESTION — one sentence describing a simple visual that would complement the copy
Empty screens:
[list 3-5 screens — e.g., "dashboard with no projects, inbox with no messages, analytics with no data yet, team page with only the current user, search results with no matches"]
Rules:
- Never say just "Nothing here" or "No data." That's a dead end.
- The headline should make the empty screen feel like a PROMISE, not a void.
- The CTA should be the single most obvious next step — not a link to docs.
- For search-no-results: suggest what to try differently (spell check, broader terms, filters).
- Keep the tone encouraging, not patronizing. No "Don't worry!" or "Looks like you haven't..."
- Tone: [match your product's voice]The best products make empty states feel like starting lines, not error screens. If your five-second test reveals confusion on first use, your empty states are probably the problem.
Error messages & recovery text
Error messages are high-stakes microcopy. The user just hit a wall. They're frustrated. Your copy either helps them recover or drives them away. Most error messages fail because they describe the problem from the system's perspective instead of the user's.
I need error messages for a [type of application].
For each error scenario, write:
1. ERROR TITLE (3-7 words) — what went wrong, in human language
2. ERROR BODY (1-2 sentences) — what the user can do to fix it, or what happens next
3. PRIMARY ACTION — button or link to recover (not just "OK" or "Dismiss")
4. SECONDARY ACTION — alternative path if the primary fix doesn't apply
Error scenarios:
[list 5-8 scenarios — e.g., "payment failed, file upload too large, session expired, feature not available on current plan, server error / something broke, permission denied, rate limit exceeded, lost internet connection"]
Rules:
- NEVER use technical jargon ("Error 403", "Request timeout", "Null reference"). Translate to human.
- NEVER blame the user ("You entered an invalid..."). Blame the situation or take responsibility ("We couldn't process...").
- Always include a recovery path. An error without a next step is a dead end.
- For server errors where you genuinely don't know what happened: be honest, apologize briefly, and give a retry + contact support option.
- For permission/plan errors: tell them exactly what they need (which plan, who to ask) — don't just say "Access denied."
- Tone: [calm and helpful — errors are not the place for cute copy]Error copy is where copy mistakes cost you the most — because the user is already on the edge of leaving. Every error is a fork: recover them, or lose them.
Tooltips & inline help text
Tooltips and help text answer questions users have right now, in context. They're the alternative to forcing someone into a docs page or help center. But bad tooltips — ones that repeat the label or explain the obvious — train users to ignore them entirely.
I need tooltip and inline help text for a [type of application].
For each UI element, write:
1. TOOLTIP TEXT (1-2 sentences, max 120 characters) — appears on hover or tap
2. LEARN MORE LINK TEXT (3-5 words) — if the tooltip needs to link to more detail
3. CONTEXTUAL HELP (1 sentence) — persistent text below or beside the element for complex features
UI elements:
[list 5-8 elements — e.g., "API key field, billing toggle (monthly/annual), privacy setting, advanced search filters, auto-save indicator, usage limit bar, team role selector, webhook URL input"]
Rules:
- A tooltip should answer ONE question: "What does this do?" or "Why should I care?"
- Never restate the label. If the label says "Auto-save" the tooltip should NOT say "This enables auto-save."
- Use the tooltip to explain the CONSEQUENCE of the setting, not just what it is. "Your drafts are saved every 30 seconds" beats "Enables automatic saving."
- For toggles and settings: explain what changes when you flip it. What's the before and after?
- If something has security or billing implications, say so explicitly in the tooltip.
- Keep tooltip text scannable — no paragraphs. If you need more than 2 sentences, it's not a tooltip, it's documentation.
- Tone: [concise and informative — tooltips should feel like a knowledgeable friend, not a manual]Good tooltips prevent support tickets. They keep users in flow instead of sending them to a docs page they'll never come back from. Pair strong tooltip writing with clear landing page copy and you eliminate confusion at every layer of the experience.