WritingCollectible prompt
Microcopy for buttons, empty states and form errors
Act as a UX writer. Write all the interface microcopy for {{page_or_feature}} on {{business_name}}'s site or app. Users are {{target_audience}}, and our voice is {{brand_voice}}.
Cover every state, not just the happy path:
- Page title and a short intro
- Form labels, hints under fields, and placeholders that never replace labels
- Buttons that start with a verb and say what happens, such as Save changes instead of Submit or OK
- Inline validation errors that say what's wrong and how to fix it
- Empty states that explain what goes here and offer the first action
- Loading and saving messages, and success confirmations
- Confirmation dialogs for anything destructive, naming what will be lost
- Tooltips, only where a label can't carry the meaning
Rules:
- Short, specific and consistent: pick one term for each thing and stick to it, such as sign in rather than mixing it with log in
- Sentence case, no blame, and no jokes in errors
- Never reveal security details, such as whether an email has an account
Return a table: element, where it appears, the copy, character count, and a note for developers. Flag any state the design seems to be missing.
Writingnvoka.com/library/nvoka-microcopy-for-buttons-empty-states-and-errorsScan to open
Writing
Microcopy for buttons, empty states and form errors
Write every small piece of interface text in one voice: labels, hints, errors and confirmations.
Curated by Nvoka
ClaudeChatGPTGemini
Make it yours
Fill in the blanks and change any word. Only your copy changes, never the card.
Fill in the blanks
0 of 4 filledYour prompt
Act as a UX writer. Write all the interface microcopy for {{page_or_feature}} on {{business_name}}'s site or app. Users are {{target_audience}}, and our voice is {{brand_voice}}.
Cover every state, not just the happy path:
- Page title and a short intro
- Form labels, hints under fields, and placeholders that never replace labels
- Buttons that start with a verb and say what happens, such as Save changes instead of Submit or OK
- Inline validation errors that say what's wrong and how to fix it
- Empty states that explain what goes here and offer the first action
- Loading and saving messages, and success confirmations
- Confirmation dialogs for anything destructive, naming what will be lost
- Tooltips, only where a label can't carry the meaning
Rules:
- Short, specific and consistent: pick one term for each thing and stick to it, such as sign in rather than mixing it with log in
- Sentence case, no blame, and no jokes in errors
- Never reveal security details, such as whether an email has an account
Return a table: element, where it appears, the copy, character count, and a note for developers. Flag any state the design seems to be missing.