I thought it was about time I refreshed my rules for what good error messages are:

• Consistant.  This could be visually consistant in the case of message boxes, or if they are being logged to a file or database table then being consistant helps them also to be machine readable.
• Informative.  Consider ADO & ADO.Net's old "General Network Error" as the best example of how not to do errors.  The key point here is the message should first say:

1. what did not work correctly, and
2. what you should do next to fix it

Stack traces etc should come later.

• Appropriate.  Consider the audience of your application.  They are the audience for your erorrs too!  The level of detail I expect in an error from SQL Server is completely different to the kind error I expect from iTunes. 
  
• Respect my attention span.  750 Event Log messages a day means I won't look at them.  Once a quater means I won't look at them.  The latter case should be emailed.  The former case probabbly should be replaced with one critical failure message
  
• Respect my privacy.  Passwords, maybe even user names, or anything that is sensative in the context of the application should not apear in an error message.  I don't have a convienient example of one with a password in it (maybe check a more complete source) but this would probabbly also extend to stack traces.

This is a growing list.  It gets revised when I see something done well, or something done poorly (or when I do something well, or when I do something poorly.  Now I've blogged it.

It started out with just the Informative rule, motivated by the cost of the support desk having to get involved in a support issue vs. the user working it out for themselves.

More formally, we could look at an error with the following criteria:

• What does this message do for the user experience?
• What does this message do to avoid the user having to call someone?