Verified against ChatGPT · 2026-08-14
Rewrite a wall of raw error messages into ones a non-technical user can actually act on
Rewrites a list of raw, developer-facing error strings into user-facing messages that state what happened, why, and the one thing to do next, without inventing a cause the system doesn't actually report.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Rewrite the raw error messages below into user-facing versions a non-technical person could actually act on. These are currently written for developers debugging the system, not for the person who just hit the error mid-task.
RAW ERROR MESSAGES
'Error 500: Internal Server Error - upstream timeout at payment-gateway-service', 'Error 422: validation failed - field "email" does not match regex'
WHERE EACH ERROR APPEARS
First error appears mid-checkout after clicking Pay; second appears on the signup form after submitting.
WHAT INFORMATION IS ACTUALLY AVAILABLE AT THE MOMENT OF THE ERROR
The payment timeout is known to be transient, usually resolves on retry within a minute, no charge is made if it fails at this step; the email validation error only knows the format didn't match, not which specific rule was violated.
For each error, write a user-facing version with three parts: what happened, stated in plain language without internal system terms (no status codes, stack traces, or internal service names); why, but only using information actually available in The payment timeout is known to be transient, usually resolves on retry within a minute, no charge is made if it fails at this step; the email validation error only knows the format didn't match, not which specific rule was violated. — if the underlying cause isn't actually known or exposed at that point in the system, say something honest and generic ("something went wrong on our end") rather than inventing a specific-sounding cause that isn't actually what the system detected, since a fabricated-but-specific cause is worse than an honest generic one because it can send a user or a support agent chasing the wrong fix; and next step, a single concrete action the user can take right now (retry, check a specific field, wait and try again, contact support with a specific reference code) rather than a vague "try again later" with no guidance on when "later" is or what changed. Match the tone to the severity of the error — a temporary network hiccup should read calmly, while an error that lost unsaved work should acknowledge that plainly rather than downplaying it. Never blame the user in the wording for something the system did (avoid phrasing that implies user error when the raw message indicates a system-side failure).
WHAT NOT TO DO
Do not soften a data-loss or security-relevant error into vague reassurance — state clearly what was and wasn't affected if that's knowable from the given context. Do not invent a specific retry time, error code, or cause that wasn't in the original raw message or the stated available information.
OUTPUT FORMAT
A table: Raw error | Where it appears | User-facing rewrite (what happened / why / next step) | Flag if the true cause isn't actually knowable at this point (meaning the rewrite had to stay honestly generic).Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Raw error strings handed to GPT-5.1 with a bare "make this user-friendly" instruction get a surface-level rewrite — friendlier words wrapped around the same underlying vagueness — because nothing in that instruction forces the model to check whether it actually knows the cause before stating one; the model will happily produce a specific-sounding explanation ("this happened because your session expired") that sounds like a real diagnosis but is actually invented, since a plausible guess is a perfectly good completion of "explain this error nicely" even when it isn't grounded in what the system actually reported. Explicitly restricting the "why" to only the information given in the available-error-info field, and requiring an honest generic fallback when the true cause isn't exposed, is what prevents this fabrication — it forces the model to treat the stated system knowledge as a hard boundary rather than a starting point to extrapolate plausibly from. The three-part structure (what / why / next step) matters because most bad error messages fail specifically at the third part — they describe a problem without ever telling the user what to actually do about it right now, leaving "try again later" as a non-answer that doesn't say when later is or what would be different — forcing a single concrete action per error closes that gap directly. Matching tone to severity, and the explicit instruction never to downplay a data-loss or security-relevant error, addresses a real and consequential failure mode in error copywriting: an error message trying too hard to sound reassuring can actively mislead a user into believing nothing serious happened when their work was in fact lost, which is a worse outcome than a blunter message that correctly conveys the actual severity of what occurred.
What you get back
Raw: 'Error 500: Internal Server Error - upstream timeout at payment-gateway-service' | Where: mid-checkout after clicking Pay | Rewrite: 'What happened: the payment step timed out before completing. Why: this is usually a brief connection issue on our end, not something wrong with your card. Next step: no charge was made — wait a few seconds and click Pay again.' | Flag: cause is knowable here (transient timeout, no charge), no generic fallback needed.
Verified against
ChatGPT GPT-5.1 · 2026-08-14
Changelog
- 2026-08-14 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — branding & design, built and maintained for you — that's Scult's day job.
EXPLORE BRANDING & DESIGN
