diff --git a/Error messages.md b/Error messages.md
new file mode 100644
index 000000000..e69de29bb
diff --git a/docs/components/charts-overview/index.mdx b/docs/components/charts-overview/index.mdx
index af644d277..0afa87d0e 100644
--- a/docs/components/charts-overview/index.mdx
+++ b/docs/components/charts-overview/index.mdx
@@ -92,8 +92,6 @@ A failure occurs when no data can be displayed within the chart. This can happen
- Explain cause: Why did the error appear? A clear and concise message explaining why the error happened, e.g. "Connection failure"
- Give solution: What can the user do to move forward? Add clear instructions for the user regarding what to do next to resolve the error, e.g. “Try again”
-For more detailed information and examples, see the [UX writing style guide](docs/guidelines/language/error-messages.md).
-
## Missing data points
Indicate missing data with a special visual marker (like a different color or shape) to highlight the gaps without connecting them.
\ No newline at end of file
diff --git a/docs/guidelines/language/best-practices.md b/docs/guidelines/language/best-practices.md
deleted file mode 100644
index dc97dd550..000000000
--- a/docs/guidelines/language/best-practices.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-sidebar_position: 7
-sidebar_label: Best practices
-title: Best practices
-doc-type: 'banner'
-component-tabs: ['']
-no_single_tab: true
-description: 'Familiarize yourself with general best practices for UX writing to maintain consistency and clarity across all your content. This section offers overarching guidelines that apply to various aspects of UX writing.'
----
-
-#
-
-## Transitional text to show something is happening
-
-- Use -ing verbs and ellipses (…)
-
-- Do not use informal, transitional wording
-
-- Confirmation messages: Use the same verb as the transitional text
-
-
-
-
-- Updating user roles…
-- Submitting log files…
-- Saving project… > Project saved
-- Training models… > Models trained
-
-
-
-
-- Getting ready…
-- Chopping fruit…
-- Saving project… > Project uploaded
-- Training models… > Training done
-
-
-
-
-## Error messages
-
-- Add a clear reason for the error
-
-- Do not blame the user
-
-- Add clear instructions for the user regarding what to do next to resolve the error
-
-- Do not over communicate
-
-- Use … to show an action is required, i.e. fill this in …
-
-
-
-
-- System error: You’re offline. Check your connection and try again.
-- File error: We cannot upload this file. Try uploading again.
-- Permission error: To carry out this task, you need more permissions. Contact admin to change permissions.
-
-
-
-
-- What did you do!?
-- The email address you entered does not match the required format. Please enter your email address using the standard format.
-
-
-
-
-## Empty-state text
-
-- Empty-state wording tells the user the empty space is intentional and should be there, i.e. not an error
-
-- Use wording to move the user forward
-
-- Use wording to help users understand the function of the empty state
-
-- Do not over communicate
-
-- Use wording to show users how to resolve the empty state, e.g. with an action, click, etc.
-
-
-
-
-- Allocate users in User management.
-- To show rows, select a project.
-- To save a project, select Save in Project detail list.
-
-
-
-
-- No allocated users.
-- No rows to show.
-- No projects saved.
-
-
-
-
-## Restoring behavior of items
-
-- Be clear on deleting, removing, creating and adding
-
-- Create goes hand in hand with Delete, it usually means it cannot be restored
-
-- Add goes hand in hand with Remove, it usually means it can be restored
-
-- Do not use Delete and Remove as synonym
-
-
-
-
-- Create a chart and delete a chart
-- Add a sensor to a chart and remove a sensor from chart
-
-
-
-
-- Create a chart and remove it
-- Add a sensor and delete the sensor
-
-
-
diff --git a/docs/guidelines/language/empty-state-messages.mdx b/docs/guidelines/language/empty-state-messages.mdx
new file mode 100644
index 000000000..0988e3fc5
--- /dev/null
+++ b/docs/guidelines/language/empty-state-messages.mdx
@@ -0,0 +1,90 @@
+---
+sidebar_position: 7
+sidebar_label: Empty-state messages
+title: Empty-state messages
+doc-type: 'banner'
+component-tabs: ['']
+no_single_tab: true
+description: 'Empty-state messages guide users, reduce confusion, and encourage meaningful action. Rather than leaving screens blank, they provide contextual messaging and clear next steps.'
+---
+
+#
+
+## Best practice template
+
+We follow this three-step approach when creating our empty-state messages. They explain why data is missing, suggest how to populate it, or offer links to relevant tools and documentation. Although not every empty-state message in a product requires all three steps, aim for this whenever possible.
+
+| Step | Purpose | Description | Example |
+| :--------- | :---------- | :--------- |:--------- |
+| 1. | Heading | Explain this is empty intentionally and should be there, i.e. this empty space is not an error. | No projects added |
+| 2. | Description | Give a clear reason why this space is empty. Provide context to help users understand the purpose of the empty-state space. | To display projects here, first add a project from your Project list. |
+| 3. | Instructions | Explain how users can fill the space by adding links, buttons and suggestions to move the user forward. | Add projects |
+
+
+## General rules
+
+Use the template when the error stops users moving forward.
+
+
+
+Heading: No zones added
+Description: Add zones to your profile to see them listed here.
+
+Button: Add zones
+
+
+
+Heading: No zones created
+Description: Add region from your dashboard.
+
+Button: Make sectors
+
+
+
+Use clear action verbs to show users how to fill the empty state.
+
+
+
+Heading: No users added
+Description: Add users in User management.
+Button: Open User management
+
+
+
+Use neutral framing of the empty state and avoid making it seem like a user failure.
+
+
+
+No users added
+
+
+
+You haven’t added any of your users
+
+
+
+Avoid “yet” or other expectation-related terms in titles.
+
+
+
+Heading: No users added
+
+
+
+Title: No users added yet
+
+
+
+## Dos and Don’ts
+
+* Do make all messages consistent in terms of grammar and punctuation
+* Do make sure users understand the space is not an error or a bug
+* Do provide an option to fill the empty space with a button or link
+* Don’t overcommunicate about the function of the empty state
+
+## Related
+
+* [Icon usage](https://ix.siemens.io/docs/icons/icon-usage#status-icons)
+* [Error messages](#)
+* [Warning messages](#)
+* [Non-critical information messages](#)
\ No newline at end of file
diff --git a/docs/guidelines/language/error-messages.md b/docs/guidelines/language/error-messages.md
deleted file mode 100644
index d4ff0bffb..000000000
--- a/docs/guidelines/language/error-messages.md
+++ /dev/null
@@ -1,101 +0,0 @@
----
-sidebar_position: 8
-sidebar_label: Errors, warnings and notifications
-title: Errors, warnings and notifications
-doc-type: 'banner'
-component-tabs: ['']
-no_single_tab: true
-description: 'Learn how to write error messages, warnings, and notifications that are helpful and user-friendly. This subchapter provides strategies for communicating issues and alerts in a way that guides users towards solutions.'
----
-
-#
-
-## General rules for messaging
-
-- Three parts of a message: 1. title 2. explanation 3. action
-
-- Title: Name which information or problem may/will occur and where it comes from
-
-- Explanation: Give a clear reason for the (potential) error and explain it’s consequences if the user ignores it
-
-- Action: Add clear instructions telling the user what to do next to resolve the error
-
-- Do not blame the user
-
-- Avoid using you and your only use passive voice as an exception
-
-- Do not repeat your message in title and explanation
-
-- Do not over communicate
-
-- Use … to show an action is required, i.e. Fill this in…
-
-- Use a polite and encouraging tone
-
-- Keep it short
-
-- If detailed information is required, consider using progressive disclosure button
-
-- Provide specific names, locations and values of the objects involved
-
-- Show urgency through wording, e.g. “immediately” only if there are serious consequences from ignoring messages
-
-## Error messages
-
-- An error message alerts user of a problem that exists and must be addressed
-
-
-
-
-- System error: You’re offline. Check your connection and try again.
-- File error: We cannot upload this file. Try uploading again.
-- Permission error: To carry out this task, you need more permissions. Contact admin to change permissions.
-
-
-
-
-- What did you do!?
-- The email address you entered does not match the required format. Please enter your email address using the standard format.
-- You have failed to delete the device.
-- Error 404
-- Value out of range.
-- File not found.
-- Title: Input error
-- Explanation: Input error detected.
-- Action: Try again.
-
-
-
-
-## Warning messages
-
-- A warning message alerts users of a condition that may cause a problem in the future
-
-
-
-
-- Title: You have not saved all documents
-- Explanation: You have to save all documents
-- Action: (OK button)
-
-
-
-
-## Notifications
-
-- Notifications are informative and no actions are required from the user
-
-
-
-
-- Access Point 2 is connected.
-- Changes are saved automatically.
-
-
-
-
-- Access Point connection failed. Try again.
-- No rows to show.
-
-
-
diff --git a/docs/guidelines/language/error-messages.mdx b/docs/guidelines/language/error-messages.mdx
new file mode 100644
index 000000000..ac6583601
--- /dev/null
+++ b/docs/guidelines/language/error-messages.mdx
@@ -0,0 +1,240 @@
+---
+sidebar_position: 8
+sidebar_label: Error messages
+title: Error messages
+doc-type: 'banner'
+component-tabs: ['']
+no_single_tab: true
+description: 'Error messages inform users when a system encounters a problem or unexpected condition. Unlike general notifications, error messages must both attract user attention and prompt corrective actions.'
+---
+
+#
+
+## Best practice template
+
+We follow this three-step approach when creating our error messages. This empowers users when encountering errors and gives them the knowledge and confidence they need to move on. For more guidance on error messages with different severity levels, see states and events.
+
+Although not every error message in a product requires all three steps, aim for this whenever possible.
+
+| Step | Purpose | Description | Example |
+| :--------- | :---------- | :--------- |:--------- |
+| 1. | Heading | Be specific and tell users exactly what happened. Effective error messages should clearly describe the issue. | No data received |
+| 2. | Description | Give a clear reason for the error and explain any consequences. Provide context to help users understand the error.| Unable to receive data as sensor is inactive. |
+| 3. | Instructions | Explain how users can move forward, resolve issues, or take action with links, buttons and suggestions. | Check sensor |
+
+
+## General rules
+
+Use the template when the error stops users moving forward.
+
+
+
+Heading: No data received
+
+Description: Unable to receive data as sensor is inactive.
+
+Instructions: Check sensor / Open sensor management
+
+
+
+Avoid generic error messages or codes; instead provide specific data, value and solutions.
+
+
+
+Failed to export data due to a connection error.
+
+
+
+ Something happened.
+
+
+
+ An error occurred.
+
+
+
+ Error 172.00046ERR
+
+
+
+
+Give clear reasons for input validation errors to ease user frustration.
+
+
+
+Value out of range. Enter a number between 1 and 100.
+
+
+
+Number between 1 and 100 required.
+
+
+
+ Invalid value.
+
+
+
+
+Avoid repeating your message in both the title and description.
+
+
+
+Bad request: Sorry, we could not process the request. Please check and try again.
+
+
+ Bad request. Sorry, bad request.
+
+
+
+
+Avoid blaming the user with “you” and “your” — use passive voice as an exception.
+
+
+
+Value out of range. Enter a number between 1 and 100.
+
+
+
+ Failed to delete device.
+
+
+
+ You have failed to delete the device.
+
+
+
+
+Provide specific and clear solutions to avoid making assumptions about user knowledge.
+
+
+
+Unsupported file type. Upload supported file types: .pdf and .docx.
+
+
+
+Unsupported file type. Upload supported file type.
+
+
+
+
+If the error is our responsibility and fault, use authentic and transparent apologies (say “sorry”)
+
+
+
+Sorry, we’ve moved this page. Please check the changelog for the new location.
+
+
+
+Sorry you entered the wrong address.
+
+
+
+
+Use “please” only for extra or unexpected user actions that correct system-caused disruptions.
+
+
+
+Heading: Page Not Found
+
+Description: We could not find what you were looking for.
+Instruction: Please contact the owner of the site that linked you to the original URL and let them know their link is broken.
+
+
+
+Show urgency with wording, e.g. “immediately” if there are consequences from ignoring the error.
+
+
+
+Update your software version immediately to avoid losing data.
+
+
+
+
+Use positive framing and avoid negative and alarming words like “wrong” and “catastrophic”.
+
+
+
+Value out of range. Enter a number between 1 and 100.
+
+
+
+Wrong number.
+
+
+
+
+Use softening words, i.e. unfortunately and avoid negative contractions (“do not” instead of “don’t”).
+
+
+
+Unfortunately, you cannot open this page.
+
+
+
+You don’t have access.
+
+
+
+You can’t open this page.
+
+
+
+
+Be honest and transparent when you cannot explain the error or how to move the user forward.
+
+
+
+Something went wrong and we couldn't complete your request. Try again later.
+
+
+
+Operation stopped for unknown reason.
+
+
+
+
+Avoid generic wording telling users to contact their admin or support as this is unhelpful.
+
+
+
+Open the chat window and paste the error into the input field for support.
+
+
+ Send error log to administrator.
+
+
+Contact admin to solve this issue.
+
+
+
+
+Avoid overpromising solutions to errors unless the team is working on the problem.
+
+
+
+ Our team is working overtime to fix this for you and it will be fixed by morning.
+
+
+
+
+
+## Dos and Don’ts
+
+* Do make all messages consistent in terms of grammar and punctuation
+* Do take the blame when the error originates from your app or product
+* Do give users a reversible solution whenever possible
+* Don’t panic your users with dramatic or urgent language
+* Don’t use all upper case characters
+
+
+## Related
+
+* [Icon usage](https://ix.siemens.io/docs/icons/icon-usage#status-icons)
+* [Warning messages]
+* [Non-critical information messages]
+* [Error pages]
+* [Empty-state messages]
+* [Form validation]
+* [Message bar]
+* [Toast messages]
+
diff --git a/docs/guidelines/language/infotips.mdx b/docs/guidelines/language/infotips.mdx
new file mode 100644
index 000000000..4c6be6fb5
--- /dev/null
+++ b/docs/guidelines/language/infotips.mdx
@@ -0,0 +1,131 @@
+---
+sidebar_position: 10
+sidebar_label: Infotips
+title: Infotips
+doc_type: 'banner'
+component-tabs: ['']
+no_single_tab: true
+description: 'Infotips are short, context-sensitive messages that appear near user interface elements to offer additional guidance or further context. Infotips or popovers are often triggered by clicking an information icon or expanding a section. For guidelines on validation and placeholder texts, see the password and logging in section.'
+---
+
+#
+
+
+## General rules
+
+Use sentence case and end with a period (similar to tooltips).
+
+
+
+View the current status of the production line.
+
+
+VIEW CURRENT STATUS OF PRODUCTION LINE
+
+
+
+
+Use infotips to support users with guidance and contextual information.
+
+
+
+Maximum allowable hydraulic pressure (bar).
+
+
+Current motor load in percentage.
+
+
+Enables automatic system recalibration.
+
+
+ Unique identifier for the production batch.
+
+
+
+
+Use infotips to help users understand complex terminology.
+
+
+
+SCADA System
+Supervisory Control and Data Acquisition: A system that monitors and controls industrial processes locally or at remote locations.
+
+
+PLC cycle time
+This indicates the time (in milliseconds) it takes for the Programmable Logic Controller to execute one full scan of its program logic.
+
+
+
+
+Use infotips to help users understand complex features.
+
+
+
+Set thresholds
+Set project thresholds here. Adjust the value to trigger alerts when the temperature exceeds a specified limit (e.g. 80°C).
+
+
+PID controller tuning
+Adjust these parameters (Proportional, Integral, Derivative) to optimize the system's response to errors and achieve stable control.
+
+
+
+
+Use infotips to help users understand complex workflows.
+
+
+
+Schedule maintenance
+This workflow guides you through planning and assigning preventive maintenance tasks. First, select the asset, then define the task type, and finally set the recurrence schedule.
+
+
+
+
+Use paragraphs to split complex information and use bullet points or lists for clarity.
+
+
+
+Power meter monitoring
+Area: Production floor
+Present consumption: 120 kW
+Peak: 150 kW
+Button: Open meter list
+
+
+
+
+Use imperative verbs (commands) for instructions and guidance.
+
+
+
+Assign a unique identifier to each physical asset for tracking, maintenance scheduling, and inventory management.
+
+
+Define and manage sequences of operations and ingredient quantities for automated production processes.
+
+
+
+
+Avoid personal pronouns (you, we, our, etc.).
+
+
+
+Select a device from the network to begin configuration.
+
+
+
+Select one of your devices to begin configuring your factory assets.
+
+
+
+
+## Dos and Don’ts
+
+* Do keep infotips short and instructional
+* Don’t include critical or legal information
+* Don’t copy your user manual into your infotips
+
+## Related
+
+* [Popover](#)
+* [Tooltips](#)
diff --git a/docs/guidelines/language/writing-style-guide-getting-started.md b/docs/guidelines/language/writing-style-guide-getting-started.md
index 596cd89c7..442c53e34 100644
--- a/docs/guidelines/language/writing-style-guide-getting-started.md
+++ b/docs/guidelines/language/writing-style-guide-getting-started.md
@@ -36,11 +36,11 @@ Get tips for naming common app functions clearly and effectively. This subchapte
## Best practice
-Familiarize yourself with general best practices for UX writing to maintain consistency and clarity across all your content. This section offers overarching guidelines that apply to various aspects of UX writing. [Read more](./best-practices)
+Familiarize yourself with general best practices for UX writing to maintain consistency and clarity across all your content. This section offers overarching guidelines that apply to various aspects of UX writing.
## Errors, warnings and notifications
-Learn how to write error messages, warnings, and notifications that are helpful and user-friendly. This subchapter provides strategies for communicating issues and alerts in a way that guides users towards solutions. [Read more](./error-messages)
+Learn how to write error messages, warnings, and notifications that are helpful and user-friendly. This subchapter provides strategies for communicating issues and alerts in a way that guides users towards solutions.
## Dialogs and buttons
diff --git a/scripts/README-markdown-to-word.md b/scripts/README-markdown-to-word.md
new file mode 100644
index 000000000..a2c79bf26
--- /dev/null
+++ b/scripts/README-markdown-to-word.md
@@ -0,0 +1,24 @@
+# Markdown → Word (DOCX) conversion
+
+This script converts Markdown files under the `docs/` directory into Word `.docx` files.
+
+Files created: `docs-word/` (preserves subfolders and filenames, `.md` → `.docx`).
+
+Requirements
+- `pandoc` installed and available on `PATH` (recommended).
+
+Quick install (macOS Homebrew):
+```bash
+brew install pandoc
+```
+
+Usage
+```bash
+python3 scripts/markdown_to_word.py
+```
+
+Output example: `docs/components/button/overview.md` -> `docs-word/components/button/overview.docx`
+
+Notes
+- The script intentionally uses `pandoc` for accurate conversion of Markdown features.
+- If you need a single combined document instead of per-file DOCX, run a custom `pandoc` command (e.g., concatenate files or use a TOC input file).
diff --git a/scripts/markdown_to_word.py b/scripts/markdown_to_word.py
new file mode 100644
index 000000000..0b6e0cd2b
--- /dev/null
+++ b/scripts/markdown_to_word.py
@@ -0,0 +1,66 @@
+#!/usr/bin/env python3
+"""
+Convert Markdown files under `docs/` to Word `.docx` using `pandoc`.
+
+Usage:
+ python3 scripts/markdown_to_word.py
+
+Outputs are written to `docs-word/` preserving subdirectory structure.
+This script prefers `pandoc` (recommended). If `pandoc` is not found it
+prints installation instructions.
+"""
+import os
+import shutil
+import subprocess
+from pathlib import Path
+
+ROOT = Path(__file__).resolve().parents[1]
+DOCS_DIR = ROOT / "docs"
+OUT_DIR = ROOT / "docs-word"
+
+
+def find_pandoc() -> bool:
+ return shutil.which("pandoc") is not None
+
+
+def convert_with_pandoc(md_path: Path, out_path: Path) -> None:
+ out_path.parent.mkdir(parents=True, exist_ok=True)
+ cmd = ["pandoc", str(md_path), "-o", str(out_path)]
+ try:
+ subprocess.run(cmd, check=True)
+ print(f"Converted: {md_path} -> {out_path}")
+ except subprocess.CalledProcessError as e:
+ print(f"pandoc failed for {md_path}: {e}")
+
+
+def collect_markdown_files(base: Path):
+ for root, dirs, files in os.walk(base):
+ # skip hidden directories
+ dirs[:] = [d for d in dirs if not d.startswith(".")]
+ for f in files:
+ if f.lower().endswith(".md"):
+ yield Path(root) / f
+
+
+def main():
+ if not DOCS_DIR.exists():
+ print(f"Docs directory not found: {DOCS_DIR}")
+ return
+
+ if not find_pandoc():
+ print("pandoc not found. Please install pandoc and retry.")
+ print("macOS: brew install pandoc")
+ print("Or visit: https://pandoc.org/installing.html")
+ return
+
+ print(f"Writing docx files to: {OUT_DIR}")
+
+ for md in collect_markdown_files(DOCS_DIR):
+ # preserve relative path under docs/
+ rel = md.relative_to(DOCS_DIR)
+ out_path = OUT_DIR / rel.with_suffix(".docx")
+ convert_with_pandoc(md, out_path)
+
+
+if __name__ == "__main__":
+ main()