docs: adjust titles and headlines (#3969)

docs/content/introduction/governance-values.mdx → docs/content/introduction/governance-principles.mdx

@@ -1,5 +1,5 @@
 ---
-title: Governance values and principles
+title: Governance Principles
 caption: Our governance values and principles on how we make decisions in the design system.
 order: 7
 badge: new

docs/content/introduction/governance-process.mdx

@@ -1,13 +1,13 @@
 ---
-title: Governance process
+title: Governance Process
 caption: Making changes and additions to Marigold.
 order: 6
 badge: new
 ---
 
 Product teams are primarily focused on getting the job done. In their quest to achieve this, they sometimes need to take on design debt—improvising styles, crafting unique components, or even bypassing the design system entirely. To help teams avoid unnecessary debt, we've established a governance process that guides both the product teams and us on managing changes and additions within Marigold.
 
-This process ensures that any modifications to the design system are carefully evaluated to maintain consistency, stability, and user-friendliness. We prioritize updates that meet specific user needs, adhere to industry standards, and offer high reusability. Guided by our [Governance values and principles](/introduction/governance-values), this approach helps uphold the quality and integrity of our design system.
+This process ensures that any modifications to the design system are carefully evaluated to maintain consistency, stability, and user-friendliness. We prioritize updates that meet specific user needs, adhere to industry standards, and offer high reusability. Guided by our [Governance values and principles](/introduction/governance-principles), this approach helps uphold the quality and integrity of our design system.
 
 If you ever asked yourself what we do with your feature requests or what you should do if we declined your request, you've come to the right place.
 

docs/content/patterns/building-forms/building-forms.mdx

@@ -107,7 +107,7 @@ Below is a basic example of extracting data from an [uncontrolled](https://react
 
 <ComponentDemo file="./building-forms-submit.demo.tsx" />
 
-## Handling complex forms and form state
+## Handling complex Forms and Form State
 
 You can simplify form handling in your React components and avoid repetitive tasks such as manually updating the form state, validating user inputs, and handling form submissions.
 We decided to use `react-form-hook` for this because its reducing re-renders caused by state updates, you don't have much to configure and supports integrating UI libraries.
@@ -117,7 +117,7 @@ In the formular we have used `<TextField>`, `<Select>` and `<Checkbox>` componen
 
 <ComponentDemo file="./building-forms-hook-form.demo.tsx" />
 
-### How to do validation and error signaling
+### How to do Validation and Error Signaling
 
 Some fields are required and throw error messages if you don't fill them out.
 For this to work, `react-hook-form` has a property `formState`, which contains the boolean `isValid`. This prop is set to `true` if the form doesn't have errors. `isValid` will always observe the entire form to validate.

docs/content/patterns/messages/messages.mdx → docs/content/patterns/feedback-messages/feedback-messages.mdx

@@ -1,5 +1,5 @@
 ---
-title: Feedback messages
+title: Feedback Messages
 caption: Learn when to use which message.
 badge: new
 ---
@@ -8,7 +8,7 @@ Messages are feedback mechanisms that inform users about important events, actio
 
 Appropriate communication of system status is critical to building trust with users, and is Jakob Nielsen’s [first usability heuristic for user interface design](https://www.nngroup.com/articles/ten-usability-heuristics/#toc-1-visibility-of-system-status-1). Too many messages, however, can dilute their usefulness and lead to alert fatigue. Therefore, it’s important to know exactly when and how to use them.
 
-## Key principles
+## Key Principles
 
 Messages should be:
 
@@ -21,7 +21,7 @@ Messages should be:
 
 Use messages to provide timely and important updates about events, actions, conditions or information that impact a user’s experience or their successful task completion. Messages can be either task-generated or system-generated.
 
-### Task-generated messages
+### Task-generated Messages
 
 Task-generated messages respond to specific user actions during a specific task. They provide immediate feedback about the effects of a user’s action.
 
@@ -31,7 +31,7 @@ For example, you may want to send a task-generated message when:
 - A file couldn’t be opened
 - The user is approaching the maximum number of items they can add to a dataset
 
-### System-generated messages
+### System-generated Messages
 
 System-generated messages communicate relevant updates about system status that aren’t triggered by a user’s current task, but may impact their experience or require their attention.
 
@@ -49,14 +49,14 @@ Don’t use messages when the information does not have a significant impact on
 - To draw attention to the status of just one UI element, you can use an [icon](/concepts/icon) with a [tooltip](/components/overlay/tooltip) for short, non-essential supporting information. (Tooltips have lower accessibility and usability across device types than messages, so do not use them for critical information.)
 - Messages that describe permanent, non-resolvable aspects or features of a page may be better communicated through headings, description text, or information architecture.
 
-## Message statuses
+## Message Statuses
 
 - **Informational**: Provides relevant information about the system’s features or content that could be worth knowing to the user.
 - **Success**: Confirms that an action was successful.
 - **Warning**: Alerts users to significant issues or changes that may require attention.
 - **Error**: Notifies users of failure states that require immediate action, or that will impede their progress until resolved.
 
-## Message components
+## Message Components
 
 <SectionMessage>
   <SectionMessage.Title>Note</SectionMessage.Title>
@@ -130,11 +130,11 @@ A [dialog](/components/overlay/dialog) is an overlay component that can be used
 
 <ComponentDemo file="./confirmation-dialog.demo.tsx" />
 
-#### Permanent dismissal
+#### Permanent Dismissal
 
 Confirmation dialogs also carry the optional feature of permanent dismissal, that is, a checkbox can be added to ensure the message is never shown again. This can be useful in cases where the user is certain they want to take a potentially dangerous action and is confident they will not need the message again in the future. Use this cautiously.
 
-#### Browser-native dialogs
+#### Browser-native Dialogs
 
 If a user takes a browser-level action that will result in data loss, like closing a browser tab, the only way to inform the user of the event and prevent data loss is by showing a browser-native confirmation dialog. These dialogs are generated by the browser itself and cannot be customized or dismissed. Show browser-native dialogs whenever users take browser-level actions that will result in data loss, including:
 
@@ -162,7 +162,7 @@ It is used to provide feedback about a user’s input, typically as part of a fo
 
 A custom-written validation message is not always required. Browsers come with their own default validation error messages that can be used in place of a customized one. See more on the [Validation](/concepts/validation) page.
 
-### Section message
+### Section Message
 
 A [section message](/components/section-message) is a block-level component that is used to alert users to something in a specific section of the screen. It is placed near the affected content in a way that clearly communicates its relationship. This is often directly above the affected section or content, but use your best judgement and place it where it makes the most sense in context.
 
@@ -175,7 +175,7 @@ A [section message](/components/section-message) is a block-level component that
   alt="Do and donts clarity"
 />
 
-## Placement and appearance
+## Placement and Appearance
 
 **Positioning**: Place messages in ways that match their urgency, communicate their relationship to the affected content, and are easy to notice.
 
@@ -185,7 +185,7 @@ A [section message](/components/section-message) is a block-level component that
 
 **Responsiveness**: Ensure messages adapt well to different screen sizes.
 
-## User interaction
+## User Interaction
 
 **Actions**: If appropriate, include ways for users to take action, like dismissing, retrying, or navigating to more details.
 
@@ -202,7 +202,7 @@ A [section message](/components/section-message) is a block-level component that
   </SectionMessage.Content>
 </SectionMessage>
 
-## Content guidelines
+## Content Guidelines
 
 **Conciseness**: Ensure messages are brief and easy to scan.
 

docs/content/patterns/overview.mdx

@@ -52,9 +52,9 @@ By adopting these patterns, designers can save time and effort, focusing instead
       ),
     },
     {
-      title: 'Feedback messages',
-      href: '/patterns/messages',
-      caption: 'Learn which message when to use.',
+      title: 'Feedback Messages',
+      href: '/patterns/feedback-messages',
+      caption: 'Learn when to use which message.',
       icon: (
         <svg
           xmlns="http://www.w3.org/2000/svg"