Syntax is the punctuation, capitalization, and the structure of the text on the screen. In UX writing, the style is often in the CSS. The structure and wording of the strings, however, are part of UX Writing. Write with consistent syntax.

Follow Existing Style Sheets

It’s the UX writer's job to design or enforce styles to control style form (as opposed to syntax). The UX writer, however, might get drawn into style form conversations. The answer is to always follow the style sheets.

Capitalization

Some elements in our UX use initial capitalization (headline style). Nouns have initial capital letters, as do some other words, such as prepositions with a length of more than 5 words.
Other elements are sentence case.
Proper nouns, such as products, are capitalized. Common nouns are not.
Don’t write UX texts all in capitals. For example, write Time Management, not TIME MANAGEMENT. In rare exceptions, such as representing code, you might need all capitals, but for the vast majority of texts, avoid all capitals.

Plurals

Never write “(s)” at the end of a word to cover both singular and plural forms (e.g., user(s)). Instead, write the plural form only. This construction doesn’t translate well into languages that use different articles or word forms for singular and plural.
Be careful when using plurals of Latin or Greek words, such as criterion or phenomenon. Use the anglicized plurals criteria and phenomena for such words, not the classical plurals criterions and phenomenons.
An exception is the word status. Here, you can use the Latin plural statuses.
Take special care with the word data. That's already a plural. If you need to render the singular, the correct form is datum.
Don't use data as singular, and don't use datas or datums as the plural.

Abbreviations

Avoid abbreviations because users can't ask what you mean by things like LOA (it's Leave of Absence).

Don't use Latin abbreviations (e.g, i.e, and etc). Write out the English equivalents instead.

Don't use the ampersand (&) to render "and". Write the word out in full.

<div> <div>Correct</div> <div>Incorrect</div> <div>Explanation</div> </div> <div> <div>Activate Time Management for Leave of Absence only.</div> <div>Activate Time Management for LOA only.</div> <div>You need all those words, so even though it's long, write it out.</div> </div> <div> <div>For example</div> <div>e.g.</div> <div>Don't use Latin.</div> </div> <div> <div>That is</div> <div>i.e.</div> <div>Don't use Latin.</div> </div> <div> <div>And so on</div> <div>etc</div> <div>Don't use Latin.</div> </div>

Some abbreviations are so common that they are allowed. If your non-techy friend uses an abbreviation, it's fine to use the abbreviation alone.

<div> <div>Correct</div> <div>Incorrect</div> <div>Explanation</div> </div> <div> <div>UI</div> <div>User Interface</div> <div>It's rare that you'll need to use this within UX writing. But if you do need to use it, it's ok to say UI.</div> </div> <div> <div>AI</div> <div>Artificial Intelligence</div> <div>How many news articles and YouTube videos say AI? As many ways as there are to define AI, consider the more specific user experience with AI, such as or <em>personalized content recommendations</em> or <em>automated virtual assistants</em>.</div> </div> <div> <div>ID</div> <div>IDentifier</div> <div>Write both letters in uppercase to avoid confusion with our inner id.</div> </div>

And when considering using an abbreviation, take care to ensure you're not accidentally writing something silly or rude. Here's an example:

<div> <div>Abbreviation</div> <div>Solution</div> <div>Why</div> </div> <div> <div>"the create, read, update, and delete (CRUD) operations"</div> <div>Omit the "CRUD" abbreviation. Just stick with the text, written out in full.</div> <div>The abbreviation represents a word that is distasteful in English.</div> </div>

Hyphenation

Be consistent in hyphenation. If you’re not sure how a particular term should be hyphenated, check the terminology database. If the term is not there, or if it is but the advice is inconsistent, choose one rule and stick with it for all your texts.

Example: full-day holiday, not full day holiday.

If you need to capitalize the hyphenated term – for example, because it’s a header or field label – capitalize both parts.

Example: Full-Day Holiday, not Full-day Holiday.

For comprehensive guidance on hyphenation at SAP, read English: Hyphenation in the SAP Style Guide.

Dates

Dates should be written in the localized format of the region. Dates are API driven and should come directly from the code.

Date Placeholder Text

Authors should not provide date placeholder text. Instead, date placeholders should be provided in code and should represent the date format. This ensures that customers understand the format of the date that they should provide and leads to less confusion for users.

When no date is selected, show a placeholder or hint text to indicate the correct date format. The control should show the default locale placeholder format. Date placeholders should be automatically defined in the code and should not be redefined by User Assistance.

Duration and Clock Times

In the case of duration, if you have room, use the full text, not an abbreviation, for the units of time:

Example: Your reservation expires in 1 hour 4 minutes.

But if you're short of room and need to abbreviate, distinguish between 2 possibilities:

Use the single letter abbreviations for the units of time. Don't leave a space between the digit and the abbreviation.
Example: Your reservation expires in 1h 4m. Note that the abbreviation is the same for singular and plural.

When writing times, use a colon to separate the hours and the minutes for times expressed in either 12-hour format or 24-hour format. Always use 4 figures, even if the number before the colon is under 10.

Examples: 01:24 or 15:27.

Do the same for the seconds if you need to include those.

Example: 20:23:11.

If you're using the 12-hour format, remember to include AM or PM after the time. Write them in capital letters.

Example: 03:30 PM

If you need to include both the date and the time, write the date first.

Example: Your order was posted on November 8, 2023, at 14:29.

Numbers

Always write numbers using digits, not words, even for numbers under 10. Use commas for the thousand' place and a period for numerals between 1 and 0. In other words, write the numerals for "ten thousand, one hundred and eighty-three and thirteen hundredths" as 10,183.13.

<div> <div>Correct</div> <div>Incorrect</div> <div>Explanation</div> </div> <div> <div>6</div> <div>Six</div> <div>Use digits for all numbers, even those under 10.</div> </div> <div> <div>183</div> <div>One hundred and eighty-three</div> <div>Use digits for all numbers.</div> </div> <div> <div>1,183</div> <div>1183</div> <div>Use a comma to separate thousands.</div> </div> <div> <div>10,183</div> <div>10.183</div> <div>Use a comma, not a period as a divider between hundreds, thousands, millions, and so on.</div> </div> <div> <div>5.23</div> <div>5,23</div> <div>Use a period for the decimal place.</div> </div>

Guidance on Some Specific Text Elements

<div> <div>Element</div> <div>Guidance</div> <div>Example</div> </div> <div> <div>Field labels</div> <div>Write these with initial capitals</div> <div>Time Type Filter Rule</div> </div> <div> <div>Buttons</div> <div>See specific guidance under header.</div> <div></div> </div> <div> <div>Menu items</div> <div></div> <div></div> </div> <div> <div>Dropdown lists</div> <div></div> <div></div> </div> <div> <div>Messages</div> <div>See specific guidance under the header.</div> <div></div> </div> <div> <div>Statuses</div> <div>Write these with initial capitals, but not all caps, in line with the general rule about not writing things all caps. Don't put a period after them</div> <div>Approved, not APPROVED</div> </div>

Buttons

Keep your button texts as short as possible.
Use active formulations in your button texts.
Exception: the OK button, where users are simply being asked to confirm they've read or seen something.
Avoid abbreviations, unless you're so short of space that you need them. See the guidance under the Abbreviations header for more advice on abbreviations, including some exceptions.

Messages

Messages can be a particular point of friction with users. They are of 3 main types:

Success messages
Users like to see these. Success messages tell users that they've achieved something.
Error messages
Users don't like to see these. Something has gone wrong.
Warning messages
Users need to act on these.

Whatever the kind of message, there are principles to observe when you write them.

Be friendly and helpful. Don't blame users if something has gone wrong, even if it was their fault. Instead, provide a solution.
Example: Don't write "You entered a postal code of the wrong length." Instead, write "Please enter a 5-character postal code."
Keep your language simple. If you have a choice between a very technical word and a more everyday word, use the everyday word.
Punctuate your messages correctly. Start with an initial capital and put a period at the end.
Use "please" or "sorry" where appropriate. An example would be something that is taking a long time or is particularly annoying.
Don't use exclamation points. These can convey hilarity or panic, and we don't want our users to feel those when using our product.
Don't use colons or semi-colons. Instead, break up your message into separate, shorter sentences.
Don't make your messages too long or complex. If you find that one is, consider splitting it into 2 or more messages.
Example:
You have selected 1 pending alerts for deletion. Are you sure you want to delete? To continue, select Delete. Otherwise, select Cancel.
This is ungrammatical and complicated. So, how about 2 messages?
Do you want to delete the selected pending alert?
Do you want to delete the {numOfSelected} selected pending alerts?

Phraseology

Where messages cover the same kind of thing, be consistent in the terms and grammatical structure you use.

Example: Confirmation

In many cases, where users have, say, deleted something or made changes, they are asked whether they are sure they want to proceed. Always use the same phraseology in writing such messages:

Do write: Approve order 12345?
Don’t write: Do you really want to approve order 12345?

If the message has one or more sentences in addition to the confirmation question, put them first.

Do write: Your changes will be lost. Are you sure you want to proceed?
Don’t write: Are you sure you want to proceed? Your changes will be lost.

Mobile Strings

While mobile strings should generally align with web strings for consistency, there are two key exceptions to this rule:

Mobile platforms often have character or space limits, necessitating shorter, more concise messages. For example, a long confirmation message like "Are you sure you want to do xxx?" might need to be simplified to "Do xxx?" on mobile.
The conventions for capitalization can vary between mobile and web, and even between iOS and Android. It's important to consult and adhere to the official guidelines of both iOS and Android to ensure accuracy and clarity.