Error Message UX Improver
The Error Message UX Improver takes your application's existing error messages and rewrites them into clear, human-friendly copy that tells users what happened, why it happened, and exactly what to do next. It transforms cryptic developer-facing strings like "Error 403: Forbidden" into actionable guidance that reduces confusion and support ticket volume.
Frontend developers, UX writers, product managers, and design teams use this template during UI polish phases, accessibility audits, support ticket analysis, or when building a new error handling system from scratch. It is especially valuable for developer-heavy teams without a dedicated UX writer, where error messages tend to reflect internal system states rather than user mental models.
The prompt works by requiring you to provide the technical context behind each error (what triggered it, who sees it, what recovery options exist) so the AI can write messages grounded in the actual user experience rather than producing generic platitudes. The output follows UX writing best practices: it leads with what went wrong in plain language, explains the cause without technical jargon, provides a specific recovery action, and maintains the right emotional tone (helpful, not condescending; honest, not alarming). The advanced difficulty reflects the judgment required to balance technical accuracy with user empathy.
This prompt is just the starting point
Score it with AI, optimize it with one click, track versions, and build your prompt library.
The Prompt
Rewrite the following error messages to be user-friendly and actionable:
**Application Type**: [web app / mobile app / CLI tool / API / desktop software]
**Brand Tone**: [friendly / professional / neutral / playful]
**Audience Technical Level**: [non-technical users / mixed / technical users]
For each error message below, provide the context and the current message:
**Error 1**:
- Current message: [PASTE THE CURRENT ERROR MESSAGE, e.g., "Error 403: Access denied. Invalid permissions."]
- When it appears: [DESCRIBE THE TRIGGER, e.g., "When a free-tier user tries to access a premium feature"]
- Recovery options available: [WHAT CAN THE USER ACTUALLY DO, e.g., "Upgrade plan, contact admin, or go back to dashboard"]
**Error 2**:
- Current message: [PASTE THE CURRENT ERROR MESSAGE]
- When it appears: [DESCRIBE THE TRIGGER]
- Recovery options available: [WHAT CAN THE USER ACTUALLY DO]
**Error 3**:
- Current message: [PASTE THE CURRENT ERROR MESSAGE]
- When it appears: [DESCRIBE THE TRIGGER]
- Recovery options available: [WHAT CAN THE USER ACTUALLY DO]
[Add more errors as needed]
For each error, provide:
1. **Rewritten Message** with three components:
- **Title** (5-8 words): What went wrong, in plain language
- **Body** (1-2 sentences): Why it happened and what to do next, with a specific action
- **Action button text** (2-4 words): The primary recovery action as a button label
2. **Alternate Version**: A second rewrite with a different tone or angle, so you can choose which fits better.
3. **Microcopy Notes**:
- Whether this error should be inline (next to the input field), toast/snackbar (temporary notification), modal (requires action), or full-page
- Suggested icon or visual indicator (warning triangle, info circle, red alert)
- Whether to log this error silently, show it to the user, or both
- Accessibility consideration: how a screen reader should announce this message
4. **Anti-patterns Avoided**: Explain what was wrong with the original message (e.g., used technical jargon, blamed the user, offered no recovery path, was too vague) and what principle the rewrite follows.
Follow these principles for all rewrites:
- Never blame the user ("You entered an invalid..." becomes "That format was not recognized...")
- Never use error codes as the primary message (codes can appear in small text for support reference)
- Always include at least one specific action the user can take
- Match the reading level to the audience (aim for grade 6-8 reading level for non-technical users)
- Keep the message under 30 words total (title + body) for inline and toast errors, under 60 words for modals and full-page errorsUsage Tips
- Batch your errors by category: Group validation errors, permission errors, network errors, and system errors separately. Each category has different UX patterns and tone requirements, and batching helps the AI maintain consistency within each group.
- Include the recovery options explicitly: The AI cannot invent recovery paths your application does not support. If the only option is "try again later," say so. If the user can retry, change a setting, or contact support, list all available options.
- Test rewrites with real users: Error messages are notoriously hard to evaluate in isolation. Run the rewritten messages past 3-5 users from your target audience and ask them what they would do after seeing each message. If they hesitate, the message needs another pass.
- Build an error message style guide from the output: After rewriting 10-15 errors, you will see patterns in tone, structure, and length. Document these patterns as a style guide so your team writes consistent error messages going forward without needing this prompt every time.
- Pair with error logging: For every user-facing message, ensure the original technical error (including codes and stack context) is logged server-side. This lets you simplify the user message without losing diagnostic information.
Get more from this prompt
Save it, score it with AI, optimize it, and track every version. Free to start.