Why does your error message make it feel like I messed up?

Language that blames the user kills trust before it can start.

• “Transaction failed. Try again.”
• “Insufficient funds.”
• “Signature rejected.”
• “Invalid input.”

These are not error messages. They’re accusations.

Errors Are Not the User’s Mistake

When something breaks, users aren’t thinking,

“Oh, I’ve violated the protocol rules.” They’re thinking,
“Did I break something? What do I do now?”

And yet Web3 UIs respond with cold, vague, hostile language — as if the user should have known better.

It’s the equivalent of a waiter saying,

“You ordered wrong.”

Ambiguity + Blame = Rage Quit

The most common traits of Web3 error copy:

• No reason why it failed
• No suggestion for what to do next
• Blame subtly pushed on the user
• Hiding behind technical lingo
• No acknowledgment that the UX was brittle in the first place

You can’t afford this in Web3 — where one broken interaction can make a user disappear forever.

The Problem: Designer Isn’t Present at the Panic

Designers rarely write error copy. It’s left to engineers.
And engineers write what they see:

• tx failed due to invalid nonce
• request denied
• EIP-1193 provider error

But UX writing isn’t about technical accuracy. It’s about making users feel seen — especially when something breaks.

So What Does Good Look Like?

• Instead of: “Signature rejected.”
  Try: “Signature was declined. That’s okay — you can always approve it later.”
• Instead of: “Transaction failed.”
  Try: “This transaction didn’t go through. Check your gas or try again in a few seconds.”
• Instead of: “Insufficient funds.”
  Try: “Looks like your wallet doesn’t have enough for gas. Try switching networks or reducing the amount.”

Error UX = Trust UX

Every broken flow is a moment of vulnerability. And in those moments, users are looking for:

• Reassurance that nothing is lost
• Guidance on what to do next
• Language that doesn’t make them feel dumb

If your product can meet them there, you turn frustration into trust.

The Fix Isn’t Just Copy

It’s the architecture of fallback.

• Can users retry without restarting?
• Can they cancel without consequence?
• Can the system anticipate the common errors?

Design for what breaks, not just what works. And when it breaks, speak like a guide — not a judge.

A broken flow doesn’t break trust. A badly written error does.

Why does your error message make it feel like I messed up? was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.