Writing has tone and voice, which combine to make text "sound" like a brand. Mercedes "sounds" luxurious. Disney "sounds" fun. SAP SuccessFactors "sounds" casual and confident, like a trusted, encouraging advisor.

Write in Casual Tone and Avoid Humor

Internet culture uses informal language and style when writing in and for IT products. SuccessFactors, and SAP more widely, adopts the people-centric approach (PCA) to sound informal. The workshop ZDIPCA covers PCA in depth.

There are key principles we need to follow to achieve our goals. The acronym "CIAO" is a helpful way to remember them. Here's what it stands for:

C = Clear
Everyone can understand us. We speak the language of our users.
I = Insightful
We are informed problem solvers. We use simple, inclusive language that focuses on helping our users get their job done.
A = Approachable
We speak authentically, as humans to humans. We talk about complex technology in a way that lets everyone in.
O = Optimistic
We speak with confidence about our real-world impact, inspiring our users with our positive attitude.

Avoid humor. It doesn't travel. What one group or person finds funny can be offensive or weird to another person or group.

Our products deal with serious subjects, such as payroll, benefits, career advancement, bonuses, education, and employment, and are often approached by our users under stress: What might be funny while you're designing it can sound alienating to stressed users.

Be informal, but don't be sloppy or flippant. Use standard U.S. English grammar, spelling, and punctuation

Address our users directly and informally but respect their livelihood. Take them seriously. Write in conversational English as a trusted, encouraging advisor.

Use Pronouns

Address users with the second person pronouns you and your.
Use "your" to create ownership of positive experiences (congratulations on your promotion) and avoid it in negative experiences (something went wrong saving the form).
If you're asking a question, such as in an FAQ, use the first person ("how can I log in?")
Use "their" for non-gendered, even singular pronouns ("everyone gets their own paystub view")

<div> <div>Correct</div> <div>Incorrect</div> <div>Explanation</div> </div> <div> <div>You can't sign in without a password</div> <div>Users can't sign in without a password</div> <div>Use the pronoun you to directly address the reader.</div> </div> <div> <div>Recover your password</div> <div>Recover password</div> <div>Use the possessive to bring the user into the conversation. It might be obvious that it's password, but the "your" makes it about them, especially in a short string.</div> </div> <div> <div>How can I recover my password?</div> <div>How can you recover your password?</div> <div>The correct use makes it sound like the user doesn't know. The incorrect case makes it sound like the system doesn't know how to recover a password.</div> </div> <div> <div>Your team member has been sent their assignment.</div> <div>Your team member has been sent his or her assignment.</div> <div>SAP SuccessFactors moved to the singular pronoun to follow the discourse community.</div> </div>

Use Contractions

Use contractions but keep it simple. One apostrophe per contraction (instead of I'd've). Beware the "its" and "it's" homonym in English. The former is the possessive pronoun, the latter is the contraction of "it is" or "it has."

<div> <div>Correct</div> <div>Incorrect</div> <div>Explanation</div> </div> <div> <div>You can't sign in without a password</div> <div>You cannot sign in without a password</div> <div>Use the contraction to sound more casual.</div> </div> <div> <div>Your pay slip wouldn't be issued if you didn't turn in your compliance forms.</div> <div>Your pay slip wouldn't've been issued if you didn't turn in your compliance forms.</div> <div>Double contractions show off and confuse or alienate English as a second language (ESL) users. There's no need for the double contraction.</div> </div> <div> <div>The job sometimes loses its batch number.</div> <div>The job sometimes loses it's batch number.</div> <div>Beware "its" and "it's" in English.</div> </div> <div> <div>Your team member has been sent their assignment.</div> <div>You're team member has been sent they're assignment.</div> <div>Beware "your" and "you're" and "they're," "their," and "there" in English.</div> </div>

To use contractions in online texts, you'll need to represent the apostrophe using the Unicode escape code.

Example: You can't create an absence request in this profile. "can't would be written can’t in the online text.

Don't Accuse or Plead

Don't accuse our users of doing something wrong. Accusation can appear in error messages: Instead, focus on the solution to the problem:

Likewise, don't overuse a pleading tone — words like please or kindly. When the UX is decorated with a pleading tone, we've gone too far in the opposite direction of accusatory tone. So instead of Please remember to submit your form, write Submit your form.

It is OK to use please and thank you, but do so sparingly. These words are often useful when we've inconvenienced users with system behavior.
For example, a foreground job that takes a long time to run could display a wait message like:

"This may take a few minutes. Thank you for your patience."

You can also use please in cases when the mood is imperative (a command) and when the sentence is short. Short, imperative sentences can sound brusque.
So instead of "Wait.", try "Please wait." This softens the tone while keeping the message clear.

Remember: good UX writing strikes a balance — polite but confident, helpful without blaming, and respectful without sounding overly apologetic.

<div> <div>Correct</div> <div>Incorrect</div> <div>Explanation</div> </div> <div> <div>The batch size was too big. Upload fewer than 100 rows.</div> <div>Your batch size was too big.</div> <div>Allow the user to possess positive or neutral system behavior (, for example) but don't force them to possess our mistakes (we didn't check the batch size).</div> </div> <div> <div>The batch size was too big. Upload fewer than 100 rows.</div> <div>Sorry, your batch size is too big.</div> <div>The "sorry" before the possessive speaks down to the reader. It sounds like "sorry you're not good at this."</div> </div> <div> <div>The batch size was too big. Upload fewer than 100 rows.</div> <div>Sorry, the batch size was too big. Upload fewer than 100 rows.</div> <div>The is too pleading. It's not annoying enough a problem.</div> </div> <div> <div>Please enter a postal code.</div> <div>Enter a postal code.</div> <div>The incorrect use is short and imperative. The please makes it softer.</div> </div> <div> <div>Sorry that the job is taking so long. Please wait a bit longer.</div> <div>Wait a bit longer.</div> <div>In this case, it's annoying to be locked out because a job won't run in the background. The please and sorry are appropriate here.</div> </div>

Write Clear, Concise Phrases

Use the words you need to explain an error or describe a field, but not more, even if you have plenty of space. If you see these types of words in your message, make sure they have a purpose.

Adverbs
Adjectives
Prepositional phrases

<div> <div>Correct</div> <div>Incorrect</div> <div>Explanation</div> </div> <div> <div>The upload limit is 100 rows.</div> <div>Choose a smaller batch size.</div> <div>The correct case uses a linking verb to be exact (100 rows). We're not sure what batch size means.</div> </div> <div> <div>Create a password.</div> <div>Create a password to sign in.</div> <div>The prepositional phrase "to sign in" isn't doing much work.</div> </div> <div> <div>Congratulate your coworker.</div> <div>Write a positive message of congratulations to your coworker!</div> <div>Congratulations are positive and a message by definition and it should be obvious from the interaction that you're writing it.</div> </div>

If you have a choice between a very technical term or a jargon term on one hand and a more familiar term on the other hand, choose the more familiar one.

Ask yourself if a police officer in your town would understand your jargon or your technical term. They're probably a smart person, and they might even use SAP SuccessFactors, but their job is policing your town, not understanding SAP SuccessFactors or its technology.
Ask yourself if you'd use the words in the analog case. If there were no computer, would you say "send the form for approval" if you were talking to a coworker or would you say "route the form for approval?"

<div> <div>Correct</div> <div>Incorrect</div> <div>Explanation</div> </div> <div> <div>Save the form.</div> <div>Submit the form.</div> <div>Submit is a method from JavaScript that made its way into our vocabulary (onSubmit). Most of us "save" our work.</div> </div> <div> <div>Send the form for approval.</div> <div>Route the form for approval.</div> <div>In the analog, you'd just say "send." If you were talking with your manager on the telephone, you would probably say, "hey, can I send this form to you?" You probably wouldn't say, "hey, can I route this form to you?"</div> </div> <div> <div>The feature is automatically on.</div> <div>The feature is universal.</div> <div>Would your banking app call a feature that's on by default "universal?" Or would they use the Plain English label of automatically on?</div> </div> <div> <div>Your personal information is encrypted.</div> <div>Your personal information is encrypted with TLS.</div> <div>Is the prepositional phrase "with TLS" necessary? And TLS is a technical term, would the police officer who's using SAP SuccessFactors Learning care which protocol you're using?</div> </div> <div> <div>Country/Region</div> <div>Locale</div> <div>While it's technically correct to say "select your locale," the town police officer probably doesn't know or care. They're in Germany.</div> </div>

Use Inclusive Language

Call it good manners, etiquette, or being a good citizen, our user experience treats others as we would like to be treated.

No one at SAP SuccessFactors intends to offend people, but we avoid language that makes our users associate our product with discomfort or with a rough patch in their lives.

Inclusive doesn't just mean "not offensive," it means to include the people who read or listen to our words and not just ourselves as writers or speakers of our words. It is empathy.

And it can be tricky. To help us write more inclusively, SAP has set up these resources.

The Inclusive Language Project has terminology rules and answers questions and includes SAP SuccessFactors team members.
The Inclusive Language Dictionary is a running list of troublesome words.
Taking Action on Inclusive Language is our employer's stance on our word choices.

For some help on specific terms, take a look at the Controlled Vocabulary section.

Use Accessible Strings

Accessible strings are a special consideration of inclusive language. Our user base includes people who have lost their vision, who move about the world differently, cannot hear sounds, and so on. Regardless of the group or abilities, we want to write language that includes them.

Accessible experiences, however, reckon with the meaning of the text we put into our UX. Hyphenation, string length, and captioning affect how content is perceived—regardless of the punctuation used in the string.

Some examples:

JAWS, the leading screen reader, reads punctuation. If you needed another reason to reduce the punctuation of on-screen text, you have it. Read all your punctuation out loud to understand the experience of a JAWS user. For example, JAWS reads on-screen text as on hyphen screen text. Would it be better for both JAWS users and sighted users to say simply, the punctuation of text?
When the UI has an image, the image must have ALT text and preferably a caption. Although it is outside the scope of UX writing, let's be aware that if users are required to understand binary content (such as images) without pure text as a back-up, we have designed an inaccessible user interface.
Icons need alt text. Always.
If you have a video embedded in the user interface, remember that the closed captioning is required and required to be translated. Use the SAP Video Tools to produce a caption file and translate it through our language team.

Also check the section of this site: Accessible Content