Golden Rules

GR1

Make sure that colleagues from software development, user interface design, and information development work closely together to design interface texts for Web applications.

You can reduce the amount of texts on the interface and avoid writing separate documentation.

GR2

Write texts that can be read and understood by all users:

• Use commonly-known language and expressions.
• Formulate task-oriented texts.
• Write from the user perspective, not from the system or developer perspective.
• Use the shortest words and sentences possible.
• Use only standard abbreviations defined in the Merriam Webster Collegiate Dictionary unless there is an approved SAP abbreviation in the standards and guidelines.

Even users who are not technically inclined or who are not native English speakers should be able to understand the texts quickly and easily.

GR3

Proceed as follows to provide information on the interface:

1. Use an easily understandable field descriptor.
2. If the field descriptor is not sufficient, set a link to the glossary if possible.
3. In exceptional cases, use an instruction for individual interface elements requiring user action.
4. If the other options mentioned are not sufficient, use an instruction for a group of interface elements.

These steps help you to avoid redundant information on the interface.

GR4

Use easily understandable descriptions for all entry, checkbox, and list fields as well as for all radio buttons.

The user should be able to use the application intuitively. There should be as little additional information on the interface as possible.
(If changing the descriptor would be an improvement for all other SAP applications, change it in the ABAP Dictionary. Note that changes to the length of the descriptor may affect translation.)

GR5

If possible, avoid using required input fields.

If you cannot avoid using required input fields, make sure you indicate that user entry is required.

You should only use required input fields if you have no other interface design alternative.

GR6

Provide useful default values for input fields, such as the last entry made or the current date when using date fields.

Default values help the user to enter the correct data.

GR7

• Use imperative sentences for instructions.
• When referring to employees of SAP AG or the company SAP AG, use "we" as the subject.

The user feels he or she is getting a direct response from the system.

GR8

In the LaunchPad, write the action first and then the object, for example "Change address" instead of "Address change".

The text communicates that the user performs an action.

GR9

Do not use the name of the interface element, for example "the pushbutton Change Order".

It is already apparent to the user which interface element is meant without stating it.

GR10

To clearly indicate that an example follows, use "for example". If space does not allow, use "Example:" if possible. Do not abbreviate.

Clearly indicates an example to the user.

GR11

Avoid using "please".

We are not asking the user for a favor. The user does not need motivation. The word "please" takes unnecessary space which might be needed for translation.

GR12

Avoid writing "here".

The word "here" is unnecessary because the user already knows where he or she is currently working.

GR13

Write commands in direct speech, for example "enter a date" instead of "date entry".

Users do not take direct speech personally and are not offended by it.

GR14

Use active voice in sentences, for example "The system changed your order." instead of "Your order was changed.".

Active voice avoids any confusion about who is doing the action and, thus also simplifies translation.

GR15

Use questions only in messages where user decision is required. Use a question mark at the end of a question.

Questions are only meaningful when the user must make a decision. In all other cases, a question would be inconsistent with the interface text design.

GR16

Adhere to the rules in the SAP Style Guide. Use the standards and guidelines for message short texts when formulating message texts.

These documents form the basis for these rules.

GR17

Use standard uppercase and lowercase spelling of words.

The outline shape of words helps the user to identify them quickly. The use of upper case or spaced writing distorts the outline shapes of words, making them more difficult to read. Also, words written like this are difficult for software programs (such as translation software, or grammar and spelling checkers) to recognize and process quickly.

GR18

Align all texts along left margin. Do not use justified text format.

Align numbers along right margin in tables and lists.

Varying spaces between words reduce reading speed by up to ten percent.

GR19

Highlight text that quotes actual interface text.

Highlight clearly indicates that you are quoting text.

GR20

• Use a period at the end of sentences.
• Use a colon when a sentence refers to a subsequent user action element.
• Do not use any punctuation at the end of messages that do not require user decision. When a message contains two sentences, use a semicolon between the two.

• Exclamation points would unnecessarily worry the user.
• Colons clearly indicate a relationship to the following text, fields, or functions.
• Semicolons indicate the sentences are linked.

GR21

Do not use hyphens to break up a word.

The width of the text display on the interface depends on the browser and can sometimes be adjusted by the user. Words that are broken by a hyphen are often not readjusted correctly.