I’ve spent a lot of time thinking about error messages in apps; writing them, too. While there’s nothing fun about the worst case scenario, product people must consider the end to end user experience, including the “bad” — especially the bad. A happy path tells your user who you are, but an unhappy path shows your user who you are. Are you helpful? Dismissive? Embarrassed? Exasperated? As chief communicators of the unhappy path, error messages are worthy of far more attention than we give them. Consider their functionality:
- Building user trust — People know nothing is 100% perfect, 100% of the time, but the reasonable expectation is there’s a plan to handle issues if they arise. Sloppy error messaging gives the impression of carelessness at best, incompetence at worst. (Nothing makes me sadder than an error message with random API numbers in it or a rude statement like “Failure”). Users will lose confidence in your app, regardless of how pretty or fast it is.
- Providing consistency — Just as pop-up dialogues and toasts provide visual consistency, so should the messaging provide tonal consistency. Too often error messages are written on the fly (and by several different people) without consideration of the language already used throughout the app. A change in voice is jarring and off-putting to the user. The product copywriter (you have one of those, right?) must work closely with designers and engineers to ensure that all user-facing messaging matches the personality of the UI text.
- Engaging users — Error states are a wonderful way to make allies out of your users and defuse situations that might otherwise end in abandonment. Apps should take their cue from the many clever 404 pages out there. While the format is not directly translatable, the tactics — humor, design, and a clear next step — are. Empty states, too, as discussed in the excellent “Why Empty States Deserve More Design Time” are pivotal moments in drawing users in and demonstrating/reiterating value proposition.
- Empowering users — By their nature, apps are action-oriented. Thus, the best error messages give users the power to do something — even if it’s just to restart the app or try again a little bit later.
Fully fleshing out unhappy paths and their corresponding error messages can be the difference between a happy user and one who instantly deletes your app. Always allow time to solve for such use cases — your users will appreciate the forethought and be more likely to stick around.
What am I missing? Let me know.