Intro

The mechanics of UX writing define how we apply our voice in practice. They turn principles into repeatable decisions that scale across products, teams, and languages.

Clear mechanics support all three strategic priorities:

• Suite first by ensuring consistency across the product landscape

• AI first by making language predictable and machine-readable

• People-centric by reducing ambiguity and cognitive effort for users

These guidelines are not stylistic preferences. They are standards designed to help users move confidently through complex processes.

Terminology and Standard Formulations (UXC-015)

Use the same term for the same concept everywhere.

Consistent terminology helps users build a stable mental model of the product and prevents misunderstandings, especially in complex workflows. It also enables AI systems and translation tools to interpret UI text reliably.

• Always use SAP-approved terminology for actions, objects, and states.

• Follow the standard formulations defined in product standard UXC-015.

• Avoid introducing synonyms for established terms, even if they feel stylistically appealing.

When terminology is consistent, users don’t have to stop and ask, “Is this the same thing as before?”

Refer to the product standard requirements, which contain a list of standard terms.

Readability and Clarity

UI text should be understood at a glance.

Professionals using SAP products make high-stakes decisions under time pressure. Our writing respects that reality by being direct, precise, and easy to scan.

To improve readability and clarity:

• Use simple, concrete words.
• Keep sentences short and focused.
• Describe actions in logical, chronological order.
• Prefer active voice over passive voice.
• Avoid capitalization for emphasis since structure and wording should carry meaning.
• Remove anything that doesn’t directly support the task.

Examples

English

U.S. English is the source language for SAP product content.

Using a single, consistent source language ensures clarity for a global audience and supports accurate translation.

Key guidelines:

• Use standard U.S. spelling, grammar, and punctuation.
• Use the serial (Oxford) comma.
• Choose U.S. English terms when regional differences exist.

Examples: Spelling

Present Tense

Use present tense by default.

Present tense reflects what is happening now or what generally happens in the system. It keeps instructions immediate and easy to process.

• Use present tense for system behavior and outcomes.
• Use future tense only when referring to actions that occur later and not in the next step.
• Future tense can also be used intentionally for a more conversational flow.

Examples

Second Person

Address users directly.

Use “you” and “your” to create a clear, conversational, and people-centric experience. Direct address keeps the focus on the user’s current task and eliminates unnecessary distance.

• Write from the user’s perspective.
• Use contractions where appropriate to keep the tone natural.
• Refer to third parties (such as administrators) only when necessary.

Examples

Abbreviations and Acronyms

Avoid abbreviations and acronyms in UI text whenever possible.

Abbreviations reduce readability, create ambiguity, and often fail in translation due to lack of context. Because UI text is typically consumed in short, fragmented segments, clarity must come first.

Use abbreviations only when they are:

• Widely recognized

• Industry-standard

• Approved in the SAP terminology database (currently SAPterm)

If an abbreviation is necessary, introduce the full term nearby, ideally in a heading or subheader.

Examples

Capitalization and Punctuation

Proper punctuation supports comprehension.

Follow standard U.S. English punctuation rules as defined in The Chicago Manual of Style, unless UI constraints require deviation. If you diverge, do so intentionally and consistently.

• Use punctuation to clarify meaning.
• Avoid unnecessary punctuation that adds visual clutter.
• When UI standards conflict, prioritize consistency across the product.

For more information about punctuation marks and special characters, refer to - SAP Style Guide for Technical Communication: Punctuation Marks and Special Characters on the User Interface.

Title Case vs. Sentence Case

Capitalization communicates structure and hierarchy.

• Title case is used for short UI elements such as headings, labels, and buttons.
  • Recommendation: If you’re not sure about certain words, like prepositions or determiners, try this tool: https://titlecaseconverter.com/.
• Sentence case is used for longer text, including messages, descriptions, and explanations.

This distinction improves scannability and reduces visual noise.

Title case examples

• Manage Journal Entries

• Best Sellers by Region

Sentence case examples

• System maintenance is in progress. You might experience interruptions.

• 4 days ago

• 4 items left

When in doubt, default to sentence case for readability.

Numbers and Numerals

Prefer numerals in UI text.

Space is limited on interfaces, especially on mobile devices. Numerals are faster to scan and easier to interpret.

• Use numerals for all numbers on the UI.
• Avoid mixing spelled-out numbers and numerals within the same context.
• Use spelled-out numbers only in fixed phrases (for example, third party).

The format of the number depends on the data type of the field, how long it is, and the locale you’re writing for.

For more information, refer to the UI Text Guidelines for Formatting Data.

Examples

Component-Specific Guidance

Component‑specific guidance explains how the SAP product voice is applied in recurring UI patterns. These patterns appear across products, teams, and experiences. Writing them consistently helps users recognize what’s happening, understand what’s required, and move forward with confidence.

This section focuses on messages, one of the most critical interaction points in the user experience.

Messages

Messages communicate system states, outcomes, and required actions. They appear at moments when users need clarity most. For example, while making decisions, resolving issues, or confirming important actions.

Well-written messages do three things:

1. Explain what’s happening
2. Clarify why it matters
3. Indicate what happens next (or what the user should do)

When messages are clear and predictable, users trust the system more and recover from issues faster.

Message Structure

Messages are typically presented in a message box with three parts:

• Title – Summarizes the situation or action

• Content – Provides essential details or guidance

• Actions – Enables the next step (if required)

Each part should earn its place. If information doesn’t help the user decide or act, remove it. For more information, see Message Box Anatomy.

Message Types

SAP uses five standard message types. Each type signals urgency and intent through both design and language.

• Error – Something must be corrected before the user can proceed

• Warning – A potential issue exists, but the user may continue

• Success – An action has completed as intended

• Information – Important context or updates that don’t require a decision

• Confirmation – A deliberate pause before a critical action

Always choose the weakest message type that still communicates risk or importance. Overusing errors or warnings reduces their effectiveness.

Writing Effective Message Text

Messages appear at moments of heightened attention. Users may be under time pressure, resolving errors, or confirming critical actions. As a result, message text must be especially clear, restrained, and purposeful.

When writing message content:

• Use plain, people‑centric language. Avoid code, system, or configuration details unless they are essential for resolution.
• Describe the issue clearly and explain what the user can do next. When applicable, include concrete steps to resolve the problem.
• Remain neutral and factual. Never blame the user or imply fault.
• Treat long text as intentional, not optional. Use it when it helps users understand consequences or recover safely.
• Do not repeat the short text in the long text. Each should add distinct value.
• Question whether a message is needed at all. In many cases, the best message is no message—when the product prevents the issue in the first place.

For more information, refer to UI Text Guidelines for SAP Fiori Apps - Messages.

Message Titles

Message boxes include default titles that reflect the message type, for example, Error, Warning, or Success. In most cases, these defaults are sufficient and should be left unchanged.

Replace a default title only when a more specific title improves clarity or decision‑making for the user. This should always be a deliberate content decision, not a cosmetic change.

When you customize message titles:

• Ensure the title adds meaningful context beyond the message type
• Use the same title consistently for the same scenario across the component and product
• Avoid creating multiple titles for the same kind of message

Inconsistent or overly specific titles can distract users and reduce their ability to scan and recognize message intent.

For design constraints and implementation details, refer to  SAP Design System: Replacing Placeholder Text.

Error Messages

Error messages appear when an action cannot be completed. They interrupt the workflow by design, so the content must be especially clear and calm.

A good error message:

• States the problem plainly
• Avoids technical or internal system language
• Provides a clear path to resolution

Do not blame the user or apologize on behalf of the system. Maintain a factual, steady tone that helps users get unstuck quickly.

For more information, see Message Box – Error Message.

Warning Messages

Warning messages signal risk without blocking progress. They exist to help users make informed decisions and not to discourage action.

Use warnings when:

• Data might be lost
• Information may be outdated
• An action has non‑obvious consequences

Focus on impact, not judgment.

For more information, see Message Box – Warning Message.

Success Messages

Success messages confirm that an action has completed successfully. They reinforce trust and help users feel confident moving forward.

Keep success messages:

• Brief
• Neutral
• Informative

Avoid celebratory or emotional language. The design already signals success.

For more information, see Message Box – Success Message.

Information Messages

Information messages provide context users need to acknowledge but not act on immediately.

They should:

• Be concise
• Avoid urgency
• Never interrupt unnecessarily

For more information, see Message Box – Information Message.

Confirmation Messages

Confirmation messages create a deliberate pause before irreversible or high‑impact actions.

They should:

• Clearly name the action
• Use direct, neutral language
• Avoid emotional framing

When input is required, use sentence case for prompts.

For more information, see SAP Design System: Message Box under Confirmation Message.

Related Links