UX Writing for Notifications
Foundations / Writing and Wording / UX Writing / UX Writing for Notifications
Intro
Notifications are system-generated messages that notify users about significant changes in workflows, processes, or data. They inform without interrupting work, and acting on them is optional.
This guideline defines conventions for message structure, tone, terminology, and information placement to promote consistent, clear, and actionable notifications across products.
Notifications panel
Voice and Tone Principles for Notifications
SAP product notifications use the voice of an approachable expert – someone who knows their domain deeply, communicates with clarity, and supports users without overwhelming them. They act as system-level cues within the product, delivering timely and relevant information that helps users stay informed and take action when needed.
Notifications are not marketing copy or conversation starters; they are functional, concise, and purposeful. They are delivered to channels such as the application shell bar or emails based on user settings. The right tone builds trust and reduces cognitive load.
1. Serious but supportive
- Communicate urgency and importance without creating anxiety.
- Be clear and straightforward for critical tasks, while staying calm and reassuring for routine reminders and updates.
- Don't use humor, slang, or exaggerated urgency, as they reduce credibility in enterprise environments.
Do
Submit your timesheet by 5 PM today.
Don't
Hurry up! You’re about to miss the deadline 😅
2. Formal but approachable
- Use professional but conversational tone that’s simple and human.
- Write in second person (“you”), especially when requesting users to act.
- Keep sentences short, active, and free of jargon.
Do
Your expense report is ready for approval.
Don't
The expense report submission process has been initiated and requires further action.
3. Respectful and reassuring
- Respect users’ time and attention – only surface notifications that are necessary and meaningful.
- Provide enough context to help users make informed decisions.
- Never manipulate with guilt or urgency.
Do
3 invoices are pending review. Approve them to proceed with payments.
Don't
You still haven’t approved those invoices. Don’t delay!
4. Consistent and role-aware
- Use terminology consistent with the product domain and the user’s workflow.
- Align tone and language with the user’s level of responsibility (manager, employee, admin).
- Use consistent urgency indicators and phrasing across all notifications (“Action required,” “Due today,” “Completed”).
How to Write Notifications
Notifications fall into two broad categories based on their purpose:
- Action-required notifications: Require users to do something (Reminders, Alerts).
- Passive notifications: Inform users without requiring action (Updates).
Action-required notification principles
Reminders
- Action-oriented: Clearly state what the user needs to do and by when. Use direct verbs: “Submit,” “Approve,” “Review.”
- Time-bound: Include deadlines or urgency markers to create relevance.
- Contextual: Specify what the reminder refers to (for example, task name, report period).
- Non-judgmental: Avoid guilt-driven language and emotional triggers.
- Concise: Keep the message glanceable – ideally under 80 characters.
Do
Submit your timesheet for Week 39 by 5 PM today.
Your quarterly performance review is due tomorrow.
Don't
Don’t forget about your timesheet!”
(vague, no action or context)
You still haven’t done this—why wait?”
(judgmental and unhelpful)
Alerts
- Clarity first: State what the issue is and the consequences if ignored.
- Explicit next step: Make it obvious how to resolve the situation.
- Transparent priority: Signal urgency with consistent phrases like “Action Required” or “Immediate Attention Needed.”
- Contextual relevance: Only trigger alerts for meaningful disruptions or risks.
- Avoid panic language: Communicate urgency without alarming users.
Do
Action required: Purchase Order #990123 is pending approval.
3 expense claims are overdue. Review them to avoid payment delays.
Don't
Something went wrong – please check.
(vague and unhelpful)
URGENT!!! Fix this NOW!
(alarmist and unprofessional)
Passive notifications
Updates
- Informative and reassuring: Clearly state what happened and whether any follow-up is needed.
- Concise and glanceable: Communicate in one line or short phrase.
- Outcome-focused: Lead with the result (“Completed,” “Available”).
- Contextual: Mention the relevant object, task, or system area.
- Respectful: Avoid trivial updates or repetitive confirmations.
Do
System maintenance is completed. All services are operational.
Your expense report was approved. No action is required.
Don't
Maintenance is done. Yay!
(too casual)
Your report might have been processed.
(unclear outcome)
Shell Bar Notifications
Notification item
- Title
- Description
- Product name
Title
The main message that communicates the core action or update.
- Keep under 40 characters to avoid truncation.
- Use title case.
- Lead with the action or outcome (for example, “Approve PO #990123”).
- Avoid filler words, exclamation marks, or jargon.
Description
Secondary details that add context.
- Keep under 80 characters for readability.
- Use sentence case.
- Front-load with the most useful supporting detail.
- Test variables for long values to prevent truncation.
- Avoid repeating the title.
Email Notifications
Email notification – implementation example
- Header
- Body
- Buttons (call to action)
- Footer
Subject line
The first impression determines if users will open the email.
- Front-load with value: “Approval Needed: PO #990123.”
- Keep under 60 characters to avoid truncation.
- Use urgency sparingly and with context.
- Prefer an active voice for clarity.
Optional: Header (intro line)
A short text that reinforces the subject line inside the email.
- Align with subject line; no contradictions.
- Keep concise and informative: “Your purchase order requires approval.”
- Avoid marketing-style slogans in transactional emails.
Body
The main content explains what happened and what action is needed.
- Use structured hierarchy (short paragraphs, bullet points, tables).
- Keep transactional emails under 240 characters.
- Write clearly and role-aware (manager vs. employee vs. admin).
- Avoid jargon or filler phrases.
Buttons/call to action (CTA)
The primary action that the email is designed to drive.
- Use short, action-driven text: “Approve Request,” “Submit Report.”
- Limit to one primary CTA; add secondary if absolutely needed.
- Keep under 25 characters.
- Avoid vague CTAs like “Click Here.”
- Use title case for buttons.
Footer
The closing section provides trust, compliance, and navigation.
- Use a consistent SAP footer format: support contact, copyright, terms.
- Include unsubscribe link, preference center, and SAP branding.
- Keep concise and mobile-friendly.
- Separate visually with a smaller font or divider.
Additional Considerations
SAP Generic Target Groups
The source text of SAP software is designed for a variety of target groups – decision makers, consultants/implementers, administrators, developers, and users who all have their own unique needs, abilities, and challenges. This can influence the style and tone of voice of content used in the software. [internal_only](For more information on target groups, refer to the topic "Generic Target Groups" in SAP Style Guide for Technical Communication.) [/internal_only]
SAP Product Standards
Before writing a notification, familiarize yourself with the SAP product standards that are relevant for the user interface. You don't need to know all product standards and all their requirements. Some requirements apply directly; others are just helpful background. Here are the relevant product standards:
Translation and Translatability
- Understand the user groups and the languages in which the product will be available.
- Use clear and inclusive language that can be easily understood and accurately translated.
- Do not use idioms, slang, wordplay, or culturally specific expressions that may not translate well.
- Be flexible with stylistic rules when needed to make the content clearer or more suitable for local contexts.
[internal_only] For more information, see:
Usage of Variables
Do
- Variables should only represent untranslatable items like object IDs, values, or technical names.
- Name variables clearly (for example, {sender}, {recipient}) or use numbering (for example, &1, {0}). This helps translators reorder them correctly.
- Ensure variables are placed naturally within a full sentence. For example, “Do you want to delete {documentName}?”
Don't
- Avoid translatable words (nouns, verbs, adjectives).
- Don’t break messages into static + variable parts. This leads to awkward phrasing and structural issues. For example, "Do you want to " + {action} + " the contract?"
- Avoid formatting like “day(s)” or “file(s)”. Variables should not carry grammar logic (like plural/singular). Handle such logic in code or with conditional strings.