Markus: Even a backend subsystem has a UI. The user might be another piece of software. So for the UI part, I’d consider if the reporting provides appropriate information to that other system so that it can detect and recover from the failure too. Also, I find that poor error reporting to human users is often the result of poor reporting in 3rd party components; and the developers of the system know no more about the error than they show to users.

And yes, not every part of the heuristic will apply in all situations.

Ajay: Add whatever questions you find useful. Mine were intended to be examples to help get people thinking. It seems you’ve used them as such.

Shruti: Yes! Error reporting looks different based on the readers perspective. Programmers and testers who understand a system’s architecture may find an error sufficient while it may only add to user frustration.

F unctional: The error detecting, reporting, and handling functions properly.

A ppropriate: Errors are reported at the appropriate time in an appropriate manner.

I mpact : The impact of the failure is communicated to those impacted.

L og: The error is appropriately logged; or not logged.

U ser Interface: The error is reported in the user interface in terms that the user understands.

R ecovery: The user is informed of what they need to do to recover from the error.

E motions: The error handling and reporting has a positive influence on user emotions.

agreed, FAILURE heuristic is really helpful, i will apply this to my next encounter and see how it goes.