Show notes
UX writer Leila Haddad has written more error messages than she can count. She explains why they're the most important words in any product — and the four questions every one of them should answer.
On this page
Nobody opens an app hoping to read an error message. But everyone eventually does, usually at the worst possible moment — when a payment fails, a file won't upload or a form refuses to submit for reasons it won't explain.
Leila Haddad is a UX writer who has spent most of her career on exactly these moments. She has worked on banking apps, healthcare portals and a well-known travel booking site, and she believes that error messages are the most revealing words in any product. "Anyone can write a nice welcome screen," she says. "Error messages show you whether a company actually respects you."
In this episode
- 00:00 — The worst error message Leila has ever seen
- 05:20 — Why "Oops!" makes things worse
- 12:45 — The four questions every error should answer
- 21:30 — Blame, tone and the passive voice
- 29:10 — Errors in forms: validation done right
- 36:40 — When the honest answer is "we don't know"
- 41:15 — How to start improving your product's errors tomorrow
The four questions
Leila's framework is refreshingly simple. A good error message, she argues, answers four questions for the person reading it:
- What happened? In plain language, not a code.
- Why did it happen? If you know. If you don't, say so honestly.
- Is my stuff safe? Did I lose my work? Was I charged?
- What can I do now? A clear next step, ideally one click away.
Most error messages, she says, answer none of these. "Something went wrong. Please try again later" answers none of them at all.
"An error message is a conversation with someone who's already frustrated. Act like it."
The framework echoes one of the long-standing usability heuristics popularised by the design researcher Jakob Nielsen: that systems should help users recognise, diagnose and recover from errors. Leila's contribution is to make that principle concrete enough to use at a writing desk.
Tone and blame
A large part of the conversation is about tone. Leila is no fan of the jokey error message — the cartoon character, the "Oops!", the cheerful pun. "It's fine when the stakes are low," she says. "But if someone's card has just been declined at a supermarket checkout, a joke is the last thing they want."
She is equally wary of messages that blame the user, even subtly. "You entered an invalid date" puts the fault on the person. "We couldn't recognise that date — try the format DD/MM/YYYY" shares the problem and offers a way out.
Forms done right
For form validation, Leila's advice is practical and specific:
- Validate as early as is helpful, but not while someone is still typing.
- Put the message next to the field it refers to, not in a banner at the top.
- Never clear what someone has typed because of a single mistake.
- Tell people what format you need before they get it wrong.
When you don't know
Daniel asks the question every product team eventually faces: what do you say when the system genuinely doesn't know what went wrong?
Leila's answer: tell the truth. "Say that something unexpected happened. Say whether their work was saved. Give them a reference number they can quote to support. And make sure a human actually reads those reports." Honesty, she argues, builds more trust than a confident-sounding message that turns out to be wrong.
Key takeaways
- Error messages reveal a product's values. They're written for people who are already frustrated, often at high-stakes moments.
- Answer four questions. What happened, why, whether the user's work or money is safe, and what they can do next.
- Drop the jokes when stakes are high. A cheerful 'Oops!' reads very differently when a payment has just failed.
- Share the problem, don't assign blame. 'We couldn't recognise that date' is kinder and clearer than 'You entered an invalid date'.
- Validate forms helpfully. Show messages beside the relevant field, tell people the format in advance and never wipe what they've typed.
- Honesty beats confidence. When you don't know what went wrong, say so, confirm what was saved and give a reference number support can use.
- Start small. Rewriting your ten most common errors so each ends in a clear next step is a quick, high-impact win.
Transcript excerpt
Daniel: If a team could only change one thing about their error messages this week, what should it be?
Leila: Find the ten errors your users see most often, and rewrite them so each one ends with a clear next step. That's it. You'll be amazed how many support tickets disappear.
Mentioned in this episode
- Jakob Nielsen's usability heuristics
- Inline form validation patterns
- Writing for stressful moments in finance and healthcare products
About our guest
Leila Haddad is a UX writer and content designer with more than twelve years' experience across banking, healthcare and travel products. She leads a small content design team and runs workshops for product teams on writing for stressful moments. She describes her job as "helping software apologise properly." Before moving into technology, she worked as a subeditor at a regional newspaper, which she credits with teaching her to cut every word that doesn't earn its place.
Credits
Signal is hosted by Maya Chen and Daniel Osei. Maya was away this week; Daniel hosted solo.