Wix audited 7,643 error-related content keys and rewrote thousands of error messages in one month by forming a cross-functional team across product, dev, design, and UX writing.
Key Takeaways
Bad error messages share four traits: inappropriate tone, technical jargon, blame-passing, and being generic when the cause is actually known.
Good messages state what happened, why, what was unaffected, and give a specific next action or a Customer Care escape hatch.
Most errors are not a content problem: Wix CEO framed generic errors as failures of development and product, not writing.
Process fixes include: cross-functional error-handling team, mandatory error review one month post-launch, and UX writers empowered to reject generic fallback strings.
Writers should stop accepting “we need a generic error here” requests and instead ask why the error occurs and how often before writing anything.
Hacker News Comment Review
Strong pushback on removing technical detail: commenters argue sanitized messages hurt power users and support staff who rely on specific codes or stack context to diagnose issues.
Consensus that error codes or UUIDs are strictly better than vague strings because they are searchable, referenceable, and unambiguous even if end-users cannot interpret them directly.
Blame-framing in consumer apps drew sharp criticism independently, with Reddit’s “Oh no, you broke reddit” cited as a canonical example of blame inversion.
Notable Comments
@Groxx: Recommends embedding a UUID in errors so users can copy-paste into search and support can trace the exact error instance with zero ambiguity.
@dale_glass: Oculus desktop app showed “No headset audio” with a generic FAQ link, knowing the specific fault but refusing to surface it, illustrating exactly the failure mode this article targets.
