Overview

System message texts are essential in every product. Having consistent and clear error messages could prove very useful for troubleshooting problems and educating people on your product.

Messaging

How to Write

1
do
false

Recommended

  • Use clear, simple language.
  • Be positive.
  • Be specific. Explain what the issue is and how to put it right.
  • Be polite, but use "please" only where appropriate.
  • Use contracted forms. It will make your messages sound more natural.
1
dont
false

Not Recommended

  • Avoid filling the message with incomprehensible data.
  • Avoid excessive use of "please".
  • Avoid alarming texts or constructions which might be interpreted as blaming the user for failing.
  • Avoid using contractions when writing critical and warning messages.

Message Types

null

Success Message

An action has been performed without errors or warnings.

Use message toast for success messages. If you want the user to acknowledge the information, use dialog.

null

Information Message

You want to provide additional, non-critical information.

Use dialog for an information message when the user needs to acknowledge the information without making a decision.

null

Confirmation Message

You want to prompt the user to confirm an action before it is executed.

Use message toast for confirmation messages unless you want the user to acknowledge the confirmation. Then use dialog.

null

Error Message

An error or problem has occurred. The message contains actions you need to perform to resolve the issue.

Use dialog for error messages when you want to interrupt and force the user to acknowledge the information or make a decision. Use message strip if the error is related to a particular entity you want to display it in the content area.

null

Warning Message

A statement of fact that alerts you to a potential mistake. You may proceed with your action despite the warning.

Use message strip if the warning is related to a particular entity you want to display it in the content area. Otherwise, use dialog.

Success/Information/Confirmation Messages

<ENTITY> <Past Participle>

Use this standard formulation to indicate confirmation/success of user actions. Do not insert auxiliary verbs such as “was”.

2
do
false

Recommended

Contract created.

dont
false

Not Recommended

You have successfully created a contract.

Enter <ENTITY>

Use this pattern as instructions for data entry.

2
do
false

Recommended

Enter the company code.

dont
false

Not Recommended

Company code was not entered.

Warning Messages

You are not authorized to <ACTION>

Use this pattern to indicate lack of authorization.

2
do
false

Recommended

You are not authorized to change the contract.

dont
false

Not Recommended

You do not have change authorization for transaction SE54.

<ENTITIES> are not selected

Use this pattern to indicate selection of entities.

2
do
false

Recommended

Additional status profiles are not selected.

dont
false

Not Recommended

Missing status profiles.

<ENTITY> not found / No <ENTITY> found

Use this pattern to indicate search results.

2
do
false

Recommended

Contract not found. / No materials found.

dont
false

Not Recommended

The system did not find contract.

Error Messages

Error while / during <OPERATION> <INSTRUCTION>

Use this pattern to indicate the occurrence of a system error.

2
do
false

Recommended

Error during initialization. See log for details.

dont
false

Not Recommended

Errors were found.

You cannot <ACTION> <REASON>

Use this pattern to indicate inability to perform an action.

2
do
false

Recommended

You cannot save the planning variant. The vendor address is invalid.

dont
false

Not Recommended

Planning variant cannot be saved because of vendor address.

<ACTION> is not permitted / possible <REASON>

Use this pattern to indicate prohibition to perform an action.

2
do
false

Recommended

Deletion is not permitted for user status. Relevant authorization does not exist.

dont
false

Not Recommended

Deletion not allowed.

<ENTITY> does not exist

Use this pattern to indicate that an entity doesn't exist.

2
do
false

Recommended

Business partner does not exist.

dont
false

Not Recommended

No business partner exists.

<ENTITY> is not available <INSTRUCTION / REASON>

Use this pattern to indicate that an entity is not available. Distinguish between this pattern and the above where the entity has not been created. In this case, the entity exists but for some reason is not available.

2
do
false

Recommended

Data is not available. Define the result areas first.

dont
false

Not Recommended

No result areas.

<ENTITY> already exists

Use this pattern to indicate that an entity that the user is trying to create already exists.

2
do
false

Recommended

Class type already exists.

dont
false

Not Recommended

Class type cannot be created twice.

Cannot display <ENTITY> <REASON>

Use this pattern to indicate inability to display data.

2
do
false

Recommended

Cannot display revision status. Period is already completed.

dont
false

Not Recommended

Displaying inventory data is not possible.

Message Buttons

In a situation where the user is interrupted by the message and needs to make a decision, consider the following pattern:

<div> <div>Message Type</div> <div>Button</div> <div>Details</div> </div> <div> <div>Success and Information</div> <div>OK</div> <div>All the user can do is to acknowledge the information.</div> </div> <div> <div>Error</div> <div> <p>Close</p> <p>Use Close instead of OK as the button text for closing an error message. Use OK if the user is just acknowledging a piece of information or a group of settings.</p> <p>You can have only one action, for example, Close, or two actions, such as Manage Account and Close.</p> </div> <div>The user has to leave the message and correct the error in the software before proceeding.</div> </div> <div> <div> <p>Warning and Confirmation</p> <p>(decision questions)</p> </div> <div> <p>One or more <Action> buttons</p> <p>For example, Leave page and Cancel.</p> </div> <div> <p>The user can decide whether to proceed or to go back and correct things in the software. Note that users often scan messages and rather pay attention to the action buttons. So Yesand No buttons are not helpful and possibly dangerous because they are not self-descriptive.</p> <p>If the decision isn't critical, or the action is too long to write out on a button, you can use an OK and a Cancel button.</p> </div> </div>

See also:

Fiori Design Guideline - Message Handling

UA Documentation - Message Texts and Content Pattern