This section gives guidelines for writing messages.
Make messages short and avoid redundancy.
Do not use a Cause/Action format.
Provide as much detail as the user needs to fix the problem, but no more than necessary.
Use short but complete sentences. Use proper grammar, punctuation and capitalization.
Avoid ambiguous words. Try to use words having only one meaning. Avoid words with data processing connotations unless you are referring to a specific application function.
Say "please" wherever possible. When a message contains instructions, use please.
Use vocabulary consistent with forms boilerplate. Refer to a field by its correct name. If a field is labeled "Sales Representative," don't use the message "Please enter a different salesperson."
Address the user as "you." Talk to the user, not about the user. Users prefer friendly messages that address them directly and make them feel they control the application. "You" is also more concise and forceful than "The user...."
Avoid nonspecific future tense. Use future tense only when your message refers to a specific time or event in the future. In other cases, "will" is usually ambiguous. For example, "Please select an invoice to cancel" is correct; whereas, "Please select an invoice that you will cancel" is incorrect.
Use active voice when possible.
Avoid accusatory messages. Do not insinuate that the user is at fault. Do not mention a user's mistake unless it pertains to the problem's solution.
Use imperative voice. For example, the message "Enter a commission plan" is better than "You can enter a commission plan."
Avoid conditionals. Use positive, imperative statements over statements containing conditionals.
Use "can" to indicate either capability or permission. Auxiliaries such as "could," "may," and "might" are ambiguous and imply more uncertainty than "can." Limit the range of uncertainty by using "can," which always implies capability or permission but does not imply chance or luck. For example, the message "You cannot delete a printed release" is preferable to "You may not delete a printed release."
Use only idiomatic abbreviations that match those used in your application's forms. If the forms that use a message do not abbreviate a term, do not abbreviate that term in a message.
Try to avoid messages with multiple possibilities, such as "Value is invalid or already exists." This requires the user to figure out which message applies to the error.
Use message numbers if there is any reasonable chance the user will need to refer to the message when communicating with Technical Support. Do not use them for simple problems like "Invalid Date."