Errors that say what's next

Support tickets that were just screenshots

Nobody assigned this. I read support tickets regularly, and kept seeing the same thing: a screenshot of an error message, and nothing else. Users weren't reporting bugs. They were asking what to do.

A user tries to cancel a payment request

They click cancel and see this:

“Did I do something wrong? What do I do now?”

The message says what failed, but not why, and not what to do next.

One bad message, or a pattern?

A few screenshots are an anecdote. I asked the backend team to export every error message the platform could show: about 2,000. The same three problems kept repeating: internal jargon, no next step, and blame.

Evidence first, then a phased plan

I brought it to my fellow designer first, and together we sorted and read the tickets. Then we took it to the product owner with two things side by side: error messages as users saw them, and the support tickets that were nothing but a screenshot and “what do I do now?”. That put it on the roadmap.

The backend team pushed back. Every rewritten message meant changes in their code, across about 2,000 messages. So we phased it: first the flows people use most and where an error costs the most (money transfers, cheques and card services), then the rest.

Trade-off: less-used flows keep their old messages for longer.

Show users only errors they can act on

Many messages were purely technical, like “FTP transfer failed”. That matters to the on-call team, not to a treasurer. Those moved to logs.

Trade-off: less raw detail on screen for curious users.

Write rules, not 2,000 one-off fixes

Fixing messages one by one would drift again with the next release. So every message has to pass three rules:

1. Say what happened, in the user's words.
2. Give the next step.
3. Never blame the user.

Trade-off: slower than quickly patching the worst messages.

AI wrote the drafts. I checked every one

In banking, a plausible rewrite can quietly change what a message says about money or permissions. So AI handled the volume, and I reviewed every message by hand.

Trade-off: slower than trusting the drafts.

When the cause isn't ours, say so

Some errors come from outside services, such as card inquiry. Neither the user nor we can fix them, so the message says what it can: try again in a few minutes, and contact support if it keeps happening. Support is the last step, there for trust, not a dead end.

Trade-off: these messages still send some users to support.

Now the message says why, and what to do

Fewer screenshots in the support queue

Error tickets that only asked “what do I do now?” went from about 6 in 10 to 3 in 10 after the first phase. Most of what's left is about how features work, not what an error means. When a rewritten message still confused people, we went back and fixed it.

The three rules are now part of how we design. Every new design specifies its error states, written to the rules, and goes to developers in a handoff format we defined.

What I learnedCopy is interface. Next time I'd link tickets to error codes from day one, to measure each message.