<div> <div>Troublesome Word</div> <div>Explanation</div> </div> <div> <div>Administrator</div> <div> <p>When you want to say write out Administrator. Don't write Admin.</p> <p>In U.S. English, often refers to someone who does the filing work around the office. In direct conversations with this key user group - the people who have veto power over our software - they asked to identify as .</p> </div> </div> <div> <div>BizX</div> <div> <p>Do not use.</p> <p>BizX, as a term, was retired more than a decade ago. We still use it conversationally within SAP SuccessFactors, but it's not a term that goes in our User Experience. When we use it, we don't agree on what it means, precisely, so it's neither clear nor concise.</p> <p>See also internal code names. We call out BizX on its own because it's so pervasive internally.</p> <p>For a list of more precise terms that you should be using instead of "BizX," go to <a href="https%3A%2F%2Fsap.sharepoint.com%2Fsites%2F205197%2FSitePages%2FSuccessFactors-Addendum-to-SAP-Style-Guide.aspx%23common-phrases-that-don-t-go-in-sap-term">SuccessFactors Addendum to SAP Style Guide</a>.</p> </div> </div> <div> <div>Case-sensitive</div> <div>The opposite of case-sensitive is case-insensitive or all lowercase letters.</div> </div> <div> <div>Dropdown, drop- down, or drop down</div> <div>Use as the noun and as the verb. Don't use drop-down at all.</div> </div> <div> <div>Email / email</div> <div>Always write it as a single word without a hyphen (email), not as e-mail.</div> </div> <div> <div>File name</div> <div>We follow the SAP Style Guide, and like other terms, it is listed here because we frequently see variations in content and on screens. The one-word form filename is especially tempting in field labels. Avoid the one-word form.</div> </div> <div> <div>Implementation consultant</div> <div> <p>Although the phrase "implementation consultant" should be rare on the user experience, if you need to refer to an expert who specializes in setting up SAP SuccessFactors for the first time, that person is an Implementation Consultant not an ADMIN.</p> <p>Capitalize normally, according to the style of the string (heading, label, sentence).</p> <p>The distinction between a partner and a consultant is like squares and rectangles (all squares are rectangles but not all rectangles are squares).</p> <ul> <li>Partner is a reserved term at SAP meaning someone who passed the certification exams and works for an established corporation that has a contract with SAP. Partners get special sign-in privileges to parts of SAP. <strong>Partners are the <em>square</em> in this example.</strong></li> <li>Consultant isn't a reserved term. A consultant can be internal to the customer, for example or it can be someone who has passed the SAP SuccessFactors certification exams but hasn't come under contract with one of the big partner houses of SAP. <strong>Consultants are the <em>rectangle</em> in this example</strong>.</li> </ul> <p>If, for some reason, you need to mean "someone who has passed all certification exams and is under contract with a big partner house and has access to partner systems in SAP", then use Partner.</p> </div> </div> <div> <div>Internal code names</div> <div> <p>We often choose an internal code name for our work as a rally cry. Don't use them externally and definitely don't use them in UX writing. Examples:</p> <ul> <li>UXR</li> <li>OneStrike</li> <li>Win With UX</li> <li>Grow SAP</li> <li>Vega</li> </ul> <p>It can be tempting, especially when these terms are about UX work, to put them on the screen, often in Administrator pages. For example, it can be tempting to say "Win With UX" on a toggle that turns on some new experience that was built under the "Win With UX" effort.</p> <p>Instead, find a more descriptive attribute of the experience to name it. For example, if the Win With UX thing we built allows importing personal data to the People Profile, then the label is something like: <strong>Import Personal Data</strong></p> </div> </div> <div> <div>Multiple employments</div> <div> <p>The phrase sounds odd because employment is a mass noun like "furniture" or "flour" — you can't count it. However, multiple employment also sounds odd because multiple implies more than one.</p> <p>When you can, add a count noun at the end (like employment record or employment instance). For example, multiple employment records.</p> <p>If you cannot add a count noun at the end, pluralize employments. Write multiple employments.status</p> </div> </div> <div> <div>Quickcard</div> <div> <p>Use one-word not two words . Write it in all lower case unless the capitalization form requires a different case.</p> <ul> <li>Open quickcard (phrase)</li> <li>List of Quick Cards (heading)</li> <li>Quick cards let you... (full sentence with quick card as subject)</li> </ul> </div> </div> <div> <div>Status</div> <div>The plural of is statuses, not stati.</div> </div> <div> <div>To-do / to-do / to do</div> <div> <p>As a singular noun, always use a hyphen (to-do)</p> <p>JAWS reads this as "TOO DASH DOO" by default, but users of screen readers have some control over how punctuation is treated and are probably accustomed to ignoring it.</p> <p>As a plural noun, turn it into a noun phrase: always use in a noun phrase with a count noun:</p> <ul> <li>to-do items</li> <li>to-do lists</li> </ul> <p>As a verb, it is two words: to do.</p> <p>Avoid "to-do" in headings because it's neither clear nor concise. It's better to use a title that conveys action "Approve These Items" instead of a description like "These Are Things." For example, if the user with the card needs to take action, the heading is Approve Requests. It should be obvious by looking at the card that it's a list. See the section on clear and concise language.</p> </div> </div> <div> <div>User / Users</div> <div> <p>You write user or users, but only if you mean it in the generic sense of "someone with sign-in privileges to our software." Otherwise, choose a more precise term. See if any of these words are more accurate:</p> <ul> <li>Applicant</li> <li>Candidate</li> <li>Recruiter</li> <li>Manager</li> <li>Human Resource Business Partner (HRBP)</li> <li>Learner</li> <li>Instructor</li> <li>Employee</li> <li>Payroll Administrator</li> <li>Learning Administrator</li> <li>(or a different precise term)</li> </ul> <p>In practice, user shouldn't appear on the UI. Chances are you want to seek approval from a manager, not seek approval from a user, for example. You want to forward a job requisition to a recruiter, not a user.</p> </div> </div> <div> <div>User name</div> <div> <p>Two words. In this case, SAP SuccessFactors follows the SAP Style Guide. We mention it here because we're often in the habit of writing it as one word: username.</p> <p>UX writers are aware of the argument that says, "but the login is jdoe, while the name is John Doe."</p> <p>And although it's true, in a vacuum, the addition or removal of the space provides meaning, UX writing isn't in a vacuum. Users see "user name" and "password" together.</p> </div> </div> <div> <div>Wifi or wi-fi</div> <div>Write this in the hyphenated form, so Wi-Fi. If you need to capitalize it, capitalize both parts, so Wi-Fi, not Wi-fi.</div> </div>