Question

If you program for a nontechnical audience, you find yourself at a high risk that users will not read your carefully worded and enlightening error messages, but just click on the first button available with a shrug of frustration.

So, I’m wondering what good practices you can recommend to help users actually read your error message, instead of simply waiving it aside. Ideas I can think of would fall along the lines of:

• Formatting of course help; maybe a simple, short message, with a “learn more” button that leads to the longer, more detailed error message
• Have all error messages link to some section of the user guide (somewhat difficult to achieve)
• Just don’t issue error messages, simply refuse to perform the task (a somewhat “Apple” way of handling user input)

Edit: the audience I have in mind is a rather broad user base that doesn’t use the software too often and is not captive (i.e., no in-house software or narrow community). A more generic form of this question was asked on slashdot, so you may want to check there for some of the answers.

Answer 1

That is an excellent question worthy of a +1 from me. The question despite being simple, covers many aspects of the nature of end-users. It boils down to a number of factors here which would benefit you and the software itself, and of course for the end-users.

• Do not place error messages in the status bar – they will never read them despite having it jazzed up with colours etc….they will always miss them! No matter how hard you’ll try… At one stage during the Win 95 UI testing before it was launched, MS carried out an experiment to read the UI (ed – it should be noted that the message explicitly stated in the context of ‘Look under the chair’), with a $100 dollar bill taped to the underside of the chair that the subjects were sitting on…no one spotted the message in the status bar!
• Make the messages short, do not use intimidating words such as ‘Alert: the system encountered a problem’, the end-user is going to hit the panic button and will over-react…
• No matter how hard you try, do not use colours to identify the message…psychologically, it’s akin to waving a red-flag to the bull!
• Use neutral sounding words to convey minimal reaction and how to proceed!
• It may be better to show a dialog box listing the neutral error message and to include a checkbox indicating ‘Do you wish to see more of these error messages in the future?’, the last thing an end-user wants, is to be working in the middle of the software to be bombarded with popup messages, they will get frustrated and will be turned off by the application! If the checkbox was ticked, log it to a file instead…
• Keep the end-users informed of what error messages there will be…which implies…training and documentation…now this is a tricky one to get across…you don’t want them to think that there will be ‘issues’ or ‘glitches’ and what to do in the event of that…they must not know that there will be possible errors, tricky indeed.
• Always, always, be not afraid to ask for feedback when the uneventful happens – such as ‘When that error number 1304 showed up, how did you react? What was your interpretation’ – the bonus with that, the end-user may be able to give you a more coherent explanation instead of ‘Error 1304, database object lost!’, instead they may be able to say ‘I clicked on this so and so, then somebody pulled the network cable of the machine accidentally’, this will clue you in on having to deal with it and may modify the error to say ‘Ooops, Network connection disconnected’… you get the drift.
• Last but not least, if you want to target international audiences, take into account of internationalization of the error messages – hence that’s why to keep it neutral, because then it will be easier to translate, avoid synonyms, slang words, etc which would make the translation meaningless – for example, Fiat Ford, the motor car company was selling their brand Fiat Ford Pinto, but noticed no sales was happening in South America, it turned out, Pinto was a slang there for ‘small penis’ and hence no sales…
• (ed)Document the list of error messages to be expected in a separate section of the documentation titled ‘Error Messages’ or ‘Corrective Actions’ or similar, listing the error numbers in the correct order with a statement or two on how to proceed…
• (ed) Thanks to Victor Hurdugaci for his input, keep the messages polite, do not make the end-users feel stupid. This goes against the answer by Jack Marchetti if the user base is international…

Edit: A special word of thanks to gnibbler who mentioned another extremely vital point as well!

• Allow the end-user to be able to select/copy the error message so that they can if they do so wish, to email to the help support team or development team.

Edit#2: My bad! Whoops, thanks to DanM who mentioned that about the car, I got the name mixed up, it was Ford Pinto…my bad…

Edit#3: Have highlighted by ed to indicate additionals or addendums and credited to other’s for their inputs…

Edit#4: In response to Ken’s comment – here’s my take…
No it is not, use neutral standard Windows colours…do not go for flashy colours! Stick to the normal gray back-colour with black text, which is a normal standard GUI guideline in the Microsoft specifications..see UX Guidelines (ed).

If you insist on flashy colours, at least, take into account of potential colour-blind users i.e. accessibility which is another important factor for those that have a disability, screen magnification friendly error messages, colour-blindness, those that suffer with albino, they may be sensitive to flashy colours, and epileptics as well…who may suffer from a particular colours that could trigger a seizure…