Message Text
A well-designed, user-friendly program prevents a user from making mistakes. So, before adding an error message, think about how you can modify the program design or UI to prevent a user from reaching an error condition that requires a message.
One option is to proactively check for errors and request correction. If the product is designed to preempt errors in this manner, a user will rarely reach an error condition.
In cases where the program design doesn't allow for preemptive checking, build forgiveness into the software. When an error condition occurs, use a message to define the situation and provide a solution.
Always balance an intuitive and non-intrusive design with the user's need to be informed and protected. This means adding feedback messages that inform the user of a task's progress, inserting warnings that make users aware of the consequences of their actions before a problem occurs, and raising helpful error messages when necessary.
Finally, if you decide that an error condition is unavoidable, flag it early to minimize damage even if this means restricting the scope of freedom or functionality you provide. It is far better to not let a user do something rather than run the risk of their losing data.
Type and Scope
Messages have two attributes: a task and a purpose. Typically a Feedback message tracks progress to reassure a user that progress is being made, a Warning message alerts a user to preempt problems, and an Error message flags a problem and provides helpful suggestions that enable a user to deal with the situation.
The situation and its intended function determine the modal nature of a message. Modeless messages provide information that can be dealt with at any time while a modal message flags a problem that halts either a process or the entire application.
Modelessness is one of the basic features of good interface design. It gives a user control over the order in which tasks are preformed. Use a modal message only when continuing with the application processes either becomes impossible or involves the risk of data loss.
Feedback
This kind of message provides feedback and information. A message displayed to track a simulation or optimization process, for instance, lets the user know that the task is either in progress or complete. Always add a feedback message when completing the task requires more than a few seconds on an average. Percent complete and time left for completion, for example, provide meaningful progress feedback. A feedback message should almost always be modeless because it needs to inform without being intrusive.
Warning
This kind of message points out the potentially dangerous or unexpected consequences of an action. It is typically used to present options before a problem occurs and to make sure the user is aware of the consequences. It also lets users change their mind and stop the process if they wish. Design the program to add warning messages proactively but give users the option of ignoring the warning. Remember, there is a fine line between being proactive and being intrusive.
Error
This kind of message describes a problem and suggests a solution, with the emphasis on providing a solution. Add an error message when an action can't be completed or when continuing without corrective input is likely to result in data loss. When possible, change the program design to prevent an error condition, even if it means some sacrifice in the flexibility or options offered to the user. Minimize the possibility of reaching an error condition and always provide a way to exit as quickly and painlessly as possible.
Writing Messages
Could not modify the file
because the directory is locked.
Unlock the directory to modify the file.
To write a message, simply transform the situation-solution report into simple words that make sense to an average user. With the new SimExec status server you can now add variables within multi-line message text to create a problem-situation-solution structure for warning and error message text.
State the problem
Describe the problem in specific terms. Keep in mind that the user may be a novice. Don't include technical jargon or concepts needlessly; state the problem in the simplest possible terms that make sense to the user.
Example:
Could not modify the "Design.doc" file.
Explain the situation
Include an explanation to help the user understand how to better work within the system. Again, while explanations are helpful, remember, this is not a good time for elaborate details. Keep it simple yet complete by only including information that helps the user understand and deal with the problem.
Example:
The "Projects" directory is locked.
Provide a solution
Provide a solution that is simple to understand and easy to implement. It is almost always better to provide just one simple way out. Use your judgment in this matter. Remember, all the user wants is to get back to the task that was interrupted.
Example:
Unlock the directory to modify the file.
Usage and Style
We create messages so the user can understand what has happened when we can’t be there to explain. Users reading messages have other things on their minds, and they may not even be native speakers of English. Our message's need to be clear, brief, encouraging, and useful. A simple, grammatically correct, complete sentence is easy to understand and translate.
Step 1.
Step 2.
Step 3.
Clear, Concise, and Consistent
Clarity is important. Be specific. The user has just been thwarted in an attempt to accomplish a task and needs to know what to do next.
Write simple and direct sentences using an active voice in the present tense.
This is not a good time to introduce a new term. Avoid jargon. And don't try to explain everything.
Refer to tasks, items, and processes in a consistent manner throughout the program.
Keep it Short
A good rule of thumb is 150 characters including spaces. It’s about what a person can see and grasp in one glance. People read messages because they have to. Don't expect them to read a lot.
Encourage and Empower
Encouragement helps a person stay with and even overcome the problem. Use a constructive, descriptive, and helpful tone. Remember that people like to retain control even when they aren’t in control. When possible, let them decide what to do. Give them a choice, not an ultimatum.
Make it Useful
Make sure that the suggestions are both helpful and useful. The user is probably frustrated already. Just one useful suggestion is good. Too many choices may not help.