Update onramps-style-guide.mdx

src/content/docs/style-guide/writing-docs/writer-workflow/onramps-style-guide.mdx

@@ -27,14 +27,14 @@ Our in-product help content provides users with the tools they need to understan
 
 Great onramps content should:
 
-* **Be clear and concise.** Contextual help should be clear and concise. Avoid using jargon or technical terms that users may not understand.
+* **Be clear and concise.** Avoid using jargon or technical terms that users may not understand.
 * **Be written in second-person point of view to address the reader.** Address the user as `you`, such as `We couldn't find your data.` 
-* **Answer the `why` and `how` questions.** For example, a user might ask themselves, `Why is this important to me?` or "How do I use this information to improve my app performance?` Write content to help answer these questions, to understand the larger context of their application. For example, a user can learn about how APM and logs relate to each other, or how APM and infrastructure relate to each other.
-* **Provide additional context to clarify ambiguous or confusing areas in the product.** For example, if there is something that is not clearly defined in the UI, we can provide additional information to help users understand it.
+* **Answer the `why` and `how` questions.** For example, a user might ask themselves, `Why is this important?` or `How can this information help improve an app's performance?` Write content to help users answer these questions to understand the larger context of their application. For example, a user can learn about how APM and logs relate to each other, or how APM and infrastructure relate to each other.
+* **Provide additional context to clarify ambiguous or confusing areas in the product.** For example, something is not clearly defined in the UI, we can provide additional information to help users understand it. NOTE: this should be a rare edge case. The better solution when something isn't clear in the UI is to work with the team that owns it, their Product Designer, and the Content Design team to improve the UI.
 * **Help users get more out of New Relic.** Help users get the most out of New Relic. When users are able to use New Relic effectively, they are more likely to continue using our product and recommend us to others. Include information that helps users:
   * Understand what a feature is used for, and the benefits of the feature beyond the existing heading or other content. 
   * Perform specific tasks.
-  * Understand what to do next. Are there recommended follow-on actions? For example, the Apdex troubleshooting onramp provides a nice example for this. It tells users to `Compare the Apdex chart with other charts (like Web transaction time and Error rate) to look for the causes for the Apdex change.`
+  * Understand what to do next. Are there recommended follow-on actions? For example, the Apdex troubleshooting onramp provides a nice example of this. It tells users to `Compare the Apdex chart with other charts (like web transaction time and error rate) to look for the causes for the Apdex change.`
 
 <table>
     <thead>
@@ -53,17 +53,17 @@ Great onramps content should:
                 Onramps usage
             </td>
             <td>
-                Not every section of the UI requires an onramp. Use them primarily at a high level on the page. If the design calls for an onramp in a spot where you don't have much to say, then talk to the designer and/or PM for the section about modifying the design or removing the onramp.
+                Not every section of the UI requires an onramp. Use them primarily at a high level on the page. If the design calls for an onramp in a spot where you don't have much to say, then talk to the designer (Product and Content) and PM for the section about modifying the design or removing the onramp.
 
-                If the onramps content isn't in the main place where the feature is (for example, onramps content for the **Service levels** tile is on the **APM Summary** page), avoiding adding too much detail.
+                If the onramps content isn't in the main place where the feature is (for example, onramps content for the **Service levels** tile is on the **APM Summary** page), avoid adding too much detail.
             </td>
         </tr>
         <tr>
             <td>
                 Headers
             </td>
             <td>
-                Headers can be any format, as long as they're short/succinct. For example, you can use an FAQ format where the headers are in question format. Here's the **Issues** tile onramp with titles formatted into questions.
+                Headers can be any format, as long as they're short/succinct. For example, you can use an FAQ format where the headers are in question format. Just make sure to avoid using first-person pronouns; use "you/your" for users. Here's the **Issues** tile onramp with titles formatted into questions.
 
               <img
               title="Tile example"
@@ -96,18 +96,17 @@ Great onramps content should:
                 UI navigation
             </td>
             <td>
-                It's okay to add a link to docs for more details on something, but ensure that you:
+                It's okay to add a link to docs for more details on something, just keep the following in mind:
 
                 * Add a docs link if there's relevant information and it's too long to summarize/explain in onramps. 
                 * The onramps content will persist after the user clicks on something, so add a docs link if it's relevant to where the user might go next (for example, if you click on the **Issues** tile and are taken to the **Issues** page, you'll still see the onramps popup on the same page, so you may want to learn how to configure issue thresholds on this page).
                 * Avoid making a link to docs the sole content of an onramp.
-                * When linking, use the established UI style for docs links. Only use `See our docs` for the link text.
+                * When linking, use the established UI style for docs links. Only use `See our docs` for the link text followed by the external link icon.
 
-                If you want to direct users to something relevant in the UI and need to add navigation instructions. For example, if a user clicks on the **Issues** tile and they want to get alerts for issues (which is on another UI page), you can provide instructions in two ways:
-                  * (Preferred) Add a link directly to the UI page in reference (for example, "[Create an alert condition here](https://onenr.io/0kjnAlvY9Ro)).
-                  * Add a link to the docs to get more info on something (for example, "To create an alert condition, see [Create your first alert](https://docs.newrelic.com/docs/alerts-applied-intelligence/new-relic-alerts/get-started/your-first-nrql-condition/).").
+                If you want to direct users to something relevant in the UI and need to add navigation instructions. For example, if a user clicks on the **Issues** tile and they want to get alerts for issues (which is on another UI page), add a link directly to the UI page in reference (for example, "[Create an alert condition](https://onenr.io/0kjnAlvY9Ro)).
+
             </td>
         </tr>
 
     </tbody>
-</table>
+</table>