As the name signifies, the message box is a special dialog that allows us to display messages to the user. Compared to the message pop-up, we use the message box to display messages that are not related to a field on the UI, such as technical errors.
In latest design trends we formulate messages in plain language, describe the issue precisely, and suggest a constructive solution. We also try to always help the user to recognize, diagnose, and recover from messages. When we design the apps, we usually aim to prevent problems from occurring in the first place.
The messages should be self explanatory instead of just providing the information; there should also be scope for resolution in case of a problem. For example, in case of a connectivity issue, instead of “The database if offline”, we can display “You do not appear to be connected to the server. Please call the tech support at XXXXX.” and instead of “Record not found” we can display “You do not appear to be an authorized user of this system. Please contact your supervisor.”
We use the message box if:
- We want to display non-field-related messages.
- We want to interrupt the user while he or she performs an action.
- We want to display error, warning, success, confirmation, or information messages.
- We need to interrupt the user for some other reason.
- We need the user to acknowledge the message.
- We need the user to make a decision.
To avoid users getting irritated from too many pop-ups, we do not use the message box if:
- We want to display a short success message. We can use toast(s) for this.
- We can show the message directly in a form field.
The following categories of messages are used in designs:
Error messages can be triggered after the user has entered incorrect data or a system error has occurred. They should interrupt the user by displaying a dialog. A final action such as Submit cannot be carried out until the user has rectified the error.
Guidelines for error messages
- Do not just describe the problem; tell the user how to resolve it.
- In the short text, speak the language of the end user. Do not include system or configuration details.
- If the solution is more involved or technical, add a long text.
- Do not repeat the short text in the long text. They both appear together on the screen.
Warning messages highlight potential issues, but the user can still continue. This includes unintended data loss scenarios.
Success messages give feedback to the user that an action has been executed. The user needs to acknowledge the message.
Information messages provide information the user needs to acknowledge, but which does not involve a decision. The message provides information that is useful and relevant, but never critical.
Confirmation messages prompt users to confirm an action that they have triggered. The title of the message box already includes the action that has to be confirmed, such as an intended deletion or an approval.