Is it necessary for error messages to have cause and fix in them

Question

We are developing mobile applications, and our screen space is really limited. But our documentation guy is asking us to add long error messages that have cause.fix kinda format. So error messages are really getting very long and ugly. I wonder if there are best practices just for mobile applications with small screen space.

Answer 1

More Words Means Less Help

In general, you want to provide the user with the cause and the fix, especially that latter. However, you want to do this as concisely as possible. This applies to mobile, web, and desktop apps.

An error is an unexpected interruption that distracts the users from the task and frustrates achieving their goals. Users will naturally want to get back on task as quickly as possible, and will take shortcuts to do so. This means they will read as little as possible, skimming or scanning the message. They often do not read the error message at all. This is often optimal behavior. For example, if the user can simply recognize the message, they can guess the fix and not have to read the message. You want to use as few words as possible so experienced users know the fix at a quick glance, and inexperienced users can learn the fix by reading a few words. The longer the message, the less users read.

Okay to Imply Cause or Fix

This means you do not necessarily need to always follow a strict cause-fix format. If one is implied by the other, use only one. For example Don’t say, “Problem: Entered qwerts exceeds the maximum allowed. Solution: Change your entered qwerts to be less than 76.” Instead say, “Enter less than 76 qwerts.” In some cases the fix is implied by the cause. For example, it’s sufficient to say “Path C:\foo\bah not found.” You don’t have to say, “Check spelling of path.” Users will tend to assume they mistyped it, or otherwise see the misspelling immediately in the error message anyway. Sometimes the cause is too technical to be comprehensible to users, so don’t bother giving it. Just give the fix. Finally, sometimes there is no practical solution worth giving. If the users of a certain rank don't have permissions to delete, don't suggest they ask their boss for a promotion, or suggest they bribe Bob in the corner office to do it for them. Just say they don't have permission (or, often better, don't provide the delete control in the first place).

Optimize for Typical Case, Support Others

In writing your error message, assume a typical user with intermediate experience and knowledge, as indicated by your user research. Messages with sufficient information for novices tend to be too long to be read by anyone. Assume the cause is the single most common one. Don’t list multiple solutions. If two or more solutions are equally likely, then add code to determine which it is before showing any error message. Provide a “More help” link with the message to access modeless troubleshooting documentation for the edge cases of users with very low experience or unusual causes.

Format the message so that expert users can quickly recognize it. Put the key distinguishing words early in the message. Consider a unique icon for each error type (rather than the generic Error icon) that illustrates and distinguishes the problem.

Couple More Things...

As for ugliness, don’t worry about that too much. When users hit an error, one of their least concerns is how pretty it looks.

And, of course, often the best looking and most helpful message box is no message box.

Answer 2

Keep to telling your users the essentials, like how they fix the problem. No need to feed them with information that they will forget as soon as they close the message, that will only make it more troublesome to read. And often (because of information overflow) even harder for the user to figure out what they're expected to do to actually fix the issue, since the generous amount of text suddenly made the problem look a lot more serious than it actually is.

Answer 3

If it is a simple field validation error, then simply highlight the field with 1-2 word phrase like 'Mandatory Field' or 'Only Numeric'

If it data-validation error from server, then show the message on top in red (also highlight failed fields)

If error is not because of user input, then show a small dialog box which will prompt them to respond, for example if network not available show dialog pop-up "Network not available, please try after sometime", or "Your Session expired, click OK to login again".

I wouldn't go with a fixed thumb rule on how to deal with errors, rather go case by case or even make sure that UI prevents the error than handling it.

Answer 4

I've observed something that I'd call error message blindness when users see an error and just abandon their task regardless of whether the situation is fixable or not. This was with a high frequency, performance incentivized user group but I think that the lessons are generalizable.

1. Keep the message as short as possible. Less is more. Users tend to scan more than read error messages. If there isn't a clear simple action to take, the user may assume that they can't fix it and could abandon the task.
2. If possible, combine the cause and solution into one statement. Some errors are simple and some are complex and require specific instructions for correcting them. This is a judgement call and decisions should be validated with usability testing.
3. Create distinct styles for different error types. For example, fixable errors should be visually communicated differently from unfixable ones. Otherwise, users could learn to make quick wrong assumptions about whether or not they should abandon. Users make decisions based on a lot of inputs and reading text is not always one of them, especially high frequency users.