What is the value of providing context-specific icons over a generic icon in a dialog?

Question

Background: Need to design icons for Dialogs in a medical enterprise application. These icons(non-actionable) will be used in Dialogs like Error, Warning, Alarm etc.

Question: What is the value of providing context-specific icons over a generic icon for a dialog? For eg. If an Error message is thrown at the user while performing a Task. Let's assume that the error was caused due to a network disconnect. Would it help to represent that Error message with a generic error icon or the icon need to be specific to the nature of the problem Ie. an icon representing network + error vs a generic Error icon

Larger concern here is from an experience standpoint for a user consuming these dialogs. Will the user understand and respond better to dialogs if the icons were context specific and be more aware of the nature of a dialog.

Need some sound UX advice on this.

Answer 1

System status vs. task failure are two separate issues. You can indicate both.

There's two errors here, and issues of time: things that are happening regardless of user input, and failure of user input (due to several possible causes).

System status isn't an error itself, but a state a user should be aware of if possible.

In this example, if I as a user am aware of connection issues beforehand if possible, I might delay doing work that I'm concerned won't persist or be successfully completed. I can anticipate errors because the system keeps me informed.

From the Neilsen Norman Group's 10 usability heuristics:

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

You could do this through a persistent info or warning band. This way the user might still use the system, but not make changes.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Errors could be handled with a single icon, but the text should be clear about what just happened, and a way to recover if possible. And inline validation can catch user input errors before the user submits their work (no dialog needed!).

Enterprise software is notorious (I do it for a living!) for having lots of error codes from a complex system where often the programmers are writing the error codes so that they can debug while they are coding. These often slip through the cracks.

Here's another reference from Neilsen Norman on designing for errors

Constructive advice on how to fix the problem. For example, instead of saying "out of stock," your error message should either tell users when the product will be available or provide a way for users to ask to be notified when the product is restocked.

In conclusion, you have two levels of information for your users:

1. A potential and persistent warning that's visible: system status. This in itself could eliminate some potential loss of work.
2. The error itself: If it was caused by a network problem (or other system issue out of their control), at least you've provided feedback for them to draw some conclusions about what may have happened.

Lastly, check your tech stack to see if you can use offline storage.

I don't know if you have the resources, but you could take advantage of offline storage through Progressive Web Apps. That is a whole other thread in itself, more suitable to discussions with your development team. Most enterprise software has significant technical debt, and doesn't get rewritten often, but just putting it out there. :)

Answer 2

if users should take a particular action when they see a particular dialog, go for distinct icons that would help them decide what to do

if there is only 1 thing they can do (like "come back later"), or if the dialogs are shown very rarely so they cannot learn the meaning of different icons, then single icon is enough IMHO