docs: blog post on messaging

blog/2026-02-23-messaging/index.md

@@ -0,0 +1,127 @@
+---
+slug: messaging
+authors: [felixleist]
+tags: [ux]
+---
+
+# Beyond the toast: Mastering messaging and feedback
+
+![Effective messaging approaches](./2602_blog_messaging1.svg)
+
+Effective communication with users is of the highest priority. Providing timely, clear and contextual feedback within our applications is crucial for a smooth and intuitive user experience. While toast messages have their place, relying on them exclusively can sometimes lead to missed information or user frustration.
+
+In response to your questions about toast messages, and especially their interplay with modal dialogs, we want to guide you through our recommended best practices for displaying messages.
+
+<!-- truncate -->
+
+# The problem with over toasting
+
+![Problem with toasts](./2602_blog_messaging_toast.svg)
+
+[Toasts](/docs/components/toast/guide) are quick, non-intrusive pop-ups that provide simple feedback on a user action. They are excellent for immediate low-priority confirmations, e.g. a successful deletion.
+
+However, toasts can often be:
+- **Missed** when a modal is open or the user’s attention is elsewhere.
+- **Overwhelming** when several toasts appear in quick succession.
+- **Lacking context** due to their intentionally brief messaging.
+
+This is why, for most scenarios requiring user attention or detailed information, we recommend exploring more robust messaging patterns.
+
+# When to use what
+
+We already offer a set of components designed to handle various messaging needs. Let’s explore the alternatives to toast messages and understand when to use each one from contextual feedback to required decision making.
+
+<div class="table-full-width table-column-equal-width">
+| **Option** | **When to use** |
+| :-------------- | :-------------- | 
+| **Toast message**    | Low-priority confirmations   |
+| **[Input field feedback text](#input-field-feedback-text)**    | Immediate, field-level validation   |
+| **[Inline notification](#inline-notification-planned)**    | Noticeable, contextual feedback   |
+| **[Message bar as banner](#message-bar-as-banner)**    | Important and persistent non-blocking messages   |
+| **[Modal](#modal)**    | Critical information demanding user interaction   |
+</div>
+
+### Input field feedback text
+
+![Input feedback](./2602_blog_messaging_inputfeedback.svg)
+
+<strong>When to use it:</strong> For immediate and highly contextual feedback related to user [input fields](/docs/components/forms-validation/guide), direct feedback texts are the recommended choice. These messages appear below the input field.
+
+<strong>Why it’s better than a toast:</strong> Input field feedback is directly tied to the user’s action. It helps users correct errors and prevents frustration. A toast would be too far removed from the input field to be effective here.
+
+Examples:
+
+- Invalid email format.
+- Password too short (minimum 8 characters).
+- Required field.
+
+### Inline notification (planned)
+
+![Inline notification](./2602_blog_messaging_inlinemessage.svg)
+
+<strong>When to use it:</strong> Inline notifications appear within a specific section or component of a page, rather than spanning the entire width. We are planning on providing a component that is optimized for inline use in future.
+
+<strong>Why it’s better than a toast:</strong> An inline notification provides contextual feedback directly where it’s most relevant, without disrupting the overall page flow. It’s less intrusive than a full banner but more persistent and noticeable than a toast for localized issues, especially when other UI elements (like modals) are present.
+
+Examples:
+
+- Above a form, indicating validation errors for multiple fields.
+- Within a data table, showing a message about filtering results.
+- Inside a specific widget, providing status updates.
+
+### Message bar as banner
+
+![Message bar](./2602_blog_messaging_messagebar.svg)
+
+<strong>When to use it:</strong> Banners are ideal for important, non-blocking messages that need to persist until dismissed or resolved. These messages can be system-wide (affecting the entire application) or page-specific (relevant to a particular view). In our design system the [message bar](/docs/components/messagebar/code) component is used for banner notifications. See our UX writing section on 
+[time-related messages](/docs/guidelines/language/messaging/time-related-messages).
+
+
+<strong>Why it’s better than a toast:</strong> Unlike toasts, banners remain visible until the user takes action or the condition is resolved. This persistence ensures that important information, like a lost connection or planned maintenance, is not missed.
+
+Examples:
+
+- Connection lost. Reconnecting…
+- System maintenance scheduled for August 22nd, 02:00-04:00.
+- Your trial period ends in 7 days.
+
+### Modal
+
+![Modal](./2602_blog_messaging_messagemodal.svg)
+
+<strong>When to use it:</strong> Modals are your choice for critical information that demands immediate user attention and interaction. [Modal messages](/docs/components/message-modal/guide) are recommended for scenarios where a user needs to confirm an action, acknowledge a severe error that blocks further progress, or make a crucial decision. See our UX writing section on [messaging](/docs/guidelines/language/messaging/messages-overview).
+
+<strong>Why it’s better than a toast:</strong> Modals overlay the entire application, ensuring the user’s focus is entirely on the message. They prevent further interaction with the underlying content until dismissed, guaranteeing that critical information is seen and acted upon.
+
+Examples:
+
+- Confirming a permanent deletion.
+- Alerting the user about unsaved changes before navigating away.
+- Displaying a critical system error that requires immediate resolution.
+
+### Notification management
+
+![Notification management](./2602_blog_messaging_notificationhistory.svg)
+
+Users might miss a critical message or need to refer back to past notifications. A dedicated notification management provides a persistent record of important events and messages.
+
+<strong>When to use it:</strong> This is valuable for applications where:
+
+- Users need to see a log of system actions or changes.
+- Users need to catch up: After being away from the application, users can quickly review what they missed.
+- Complex workflows: Where multiple actions trigger various messages.
+
+<strong>How it adds value:</strong> A notification management is often presented as an [event list](/docs/components/event-list/code) on a separate page, within a dedicated dialog, or accessible via a notification icon. It ensures that no critical information is permanently lost. It complements all other messaging patterns by offering a centralized archive, allowing users to review, filter and act upon past notifications. This significantly enhances user control and confidence in the application.
+
+## Key takeaways
+
+- <strong>Prioritize clarity and context:</strong> Always choose the messaging pattern that best communicates the information clearly and in the most relevant context.
+- <strong>Reserve toasts for small feedback:</strong> Use toasts for quick, non-critical confirmations that don’t require immediate user action or detailed explanation.
+- <strong>Embrace alternatives:</strong> Leverage input field feedback for direct validation, inline notifications for contextual feedback, banners for persistent alerts, and modals for critical interactions.
+- <strong>Provide a notification management:</strong> For important events and messages, offer a persistent record that users can access and review.
+- <strong>Stay aligned:</strong> You can always refer to our component usage guides for the most up-to-date guidance and examples.
+
+## More on messaging
+
+- We highly recommend the [UX writing](/docs/guidelines/language/messaging/messages-overview) chapter on how to effectively phrase your messages depending on the context, e.g. warning messages.
+- The <strong>UX Design Pattern</strong> team is currently working on a detailed overview of messaging patterns. Follow them on [Viva Engage](https://engage.cloud.microsoft/main/org/siemens.com/groups/eyJfdHlwZSI6Ikdyb3VwIiwiaWQiOiIyMzcxMzg0NTI0ODAifQ/new) to stay tuned.

docs/guidelines/language/messaging/messages-overview.md

@@ -8,29 +8,27 @@ no_single_tab: true
 description: 'The ability to design effective messages is essential for intuitive, user-friendly interfaces that inform and support users. This page explains general UX writing rules and how to choose the right message type for your needs.'
 ---
 
-
 #
 
 ## Message types
 
 First define your use case and message type from the list below, then use this overview and the other sections for message-specific guidance and examples.
 
-
-
- | Message type                       | Usage                                                                                                                              | Best practice example                                                                                                                            |
-| :--------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------- |
-| Error messages                     | Notify users of operational issues that have already happened and require their immediate action to resolve.                       | **Heading:** No data received<br/>**Description:** Unable to receive data as sensor is inactive.<br/>**Instructions:** Check sensor              |
-| Warning messages                   | Alert users to a potential problem or risk. Advises caution or suggests different actions to prevent unwanted future consequences. | **Heading:** Temperature approaching threshold<br/>**Description:** Temperature in Zone 3 approaching 30° threshold.<br/>**Instructions:** Check zone |
-| Non-critical information messages  | Inform users about general information. Often no action is required.                                                               | System backup completed at 21:00 CET.                                                                                                            |
-| Empty-state messages               | Tell users the empty space is intentional, i.e. not an error, and how it can be filled.                                            | **Heading:** No zones created<br/>**Description:** Create zones to display on dashboard.<br/>**Button:** Create zone                             |
-| Toast messages                     | Give short and often quickly disappearing feedback to a user action.                                                               | **Heading:** Asset deleted<br/>**Description:** Valve 4a/203/22                                                                                  |
-| Tooltips                           | Provide brief additional information about the tool with contextual help. Answer the question, “What is this?”                     | Shows machine activity and operator actions.                                                                                                     |
-| Infotips                           | Provide more detailed explanations or guidance regarding user actions. Answer the question, “Why is this here and what does it do?” | Hover over icons or labels to see more details about their function or status.                                                                   |
-| Time-related messages              | Provide specific timeframes with actionable guidance.                                                                              | System maintenance scheduled for 22 August, 02:00–04:00 CEST.                                                                                    |
+| Message type                      | Usage                                                                                                                               | Best practice example                                                                                                                                 |
+| :-------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Error messages                    | Notify users of operational issues that have already happened and require their immediate action to resolve.                        | **Heading:** No data received<br/>**Description:** Unable to receive data as sensor is inactive.<br/>**Instructions:** Check sensor                   |
+| Warning messages                  | Alert users to a potential problem or risk. Advises caution or suggests different actions to prevent unwanted future consequences.  | **Heading:** Temperature approaching threshold<br/>**Description:** Temperature in Zone 3 approaching 30° threshold.<br/>**Instructions:** Check zone |
+| Non-critical information messages | Inform users about general information. Often no action is required.                                                                | System backup completed at 21:00 CET.                                                                                                                 |
+| Empty-state messages              | Tell users the empty space is intentional, i.e. not an error, and how it can be filled.                                             | **Heading:** No zones created<br/>**Description:** Create zones to display on dashboard.<br/>**Button:** Create zone                                  |
+| Toast messages                    | Give short and often quickly disappearing feedback to a user action.                                                                | **Heading:** Asset deleted<br/>**Description:** Valve 4a/203/22                                                                                       |
+| Tooltips                          | Provide brief additional information about the tool with contextual help. Answer the question, “What is this?”                      | Shows machine activity and operator actions.                                                                                                          |
+| Infotips                          | Provide more detailed explanations or guidance regarding user actions. Answer the question, “Why is this here and what does it do?” | Hover over icons or labels to see more details about their function or status.                                                                        |
+| Time-related messages             | Provide specific timeframes with actionable guidance.                                                                               | System maintenance scheduled for 22 August, 02:00–04:00 CEST.                                                                                         |
 
 ## General rules
 
 Use sentence casing for all message descriptions (except toast messages) and add full stops.
+
 <div className="dos-and-donts" markdown="true">
  <div className="dos" markdown="true">
   - Create zones from your dashboard.
@@ -42,6 +40,7 @@ Use sentence casing for all message descriptions (except toast messages) and add
 </div>
 
 Avoid overcommunicating by only adding relevant, beneficial information to your messages.
+
 <div className="dos-and-donts" markdown="true">
  <div className="dos" markdown="true">
   - We received your error report and will process it within 24 to 48 hours.
@@ -52,6 +51,7 @@ Avoid overcommunicating by only adding relevant, beneficial information to your
 </div>
 
 Provide specifics, e.g. objects, values, reasons and solutions, instead of generic messaging.
+
 <div className="dos-and-donts" markdown="true">
  <div className="dos" markdown="true">
   - Failed to upload file due to connection error.
@@ -63,6 +63,7 @@ Provide specifics, e.g. objects, values, reasons and solutions, instead of gener
 </div>
 
 Use urgent wording to signal serious and irreversible consequences from ignoring messages.
+
 <div className="dos-and-donts" markdown="true">
  <div className="dos" markdown="true">
   - Immediate software update required to save data securely.
@@ -73,6 +74,7 @@ Use urgent wording to signal serious and irreversible consequences from ignoring
 </div>
 
 Use the same key words in your messaging, but do not repeat headings and descriptions.
+
 <div className="dos-and-donts" markdown="true">
  <div className="dos" markdown="true">
   - **Heading:** Bad request<br />
@@ -85,6 +87,7 @@ Use the same key words in your messaging, but do not repeat headings and descrip
 </div>
 
 Use the same grammar patterns across all your messaging within your product.
+
 <div className="dos-and-donts" markdown="true">
  <div className="dos" markdown="true">
   - No assets added. / No dashboards created. / No data downloaded.
@@ -95,6 +98,7 @@ Use the same grammar patterns across all your messaging within your product.
 </div>
 
 Avoid asking patronizing “Are you sure…?” questions to your expert users.
+
 <div className="dos-and-donts" markdown="true">
  <div className="dos" markdown="true">
   - Deleting this file removes all dependencies.
@@ -105,6 +109,7 @@ Avoid asking patronizing “Are you sure…?” questions to your expert users.
 </div>
 
 Use action labels that match the action of the message without mixing verbs or using synonyms.
+
 <div className="dos-and-donts" markdown="true">
  <div className="dos" markdown="true">
   - Close
@@ -136,14 +141,15 @@ Allow users to go back to change actions and avoid “OK” which is often under
 </div>
 
 ## Dos and Don’ts
-*   Do first classify what kind of message is required
-*   Do make a record or changelog of your messages for consistency and changes
-*   Don’t over communicate with irrelevant or unrelated information
-*   Don’t repeat the exact same wording in both the heading and description
+
+- Do first classify what kind of message is required
+- Do make a record or changelog of your messages for consistency and changes
+- Don’t over communicate with irrelevant or unrelated information
+- Don’t repeat the exact same wording in both the heading and description
 
 ## Related
 
-*   [Icon usage](../../../icons/icon-usage.mdx)
-*   [Warning messages](./warning-messages.mdx)
-*   [Error messages](./error-messages.mdx)
-*   [Empty-state messages](./empty-state-messages.mdx) 
+- [Icon usage](../../../icons/icon-usage.mdx)
+- [Warning messages](./warning-messages.mdx)
+- [Error messages](./error-messages.mdx)
+- [Empty-state messages](./empty-state-messages.mdx)