Docs: bad-then-good applies to dev guidelines only

doc/development/documentation/structure.md

@@ -190,7 +190,7 @@ conversions can be viewed on Google Analytics by navigating to **Behavior > Even
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36576/) in GitLab 13.2 as GitLab Development documentation.
 
-'Good practice' examples demonstrate encouraged ways of writing code while comparing with examples of practices to avoid.
+"Good practice" examples demonstrate encouraged ways of writing code while comparing with examples of practices to avoid.
 These examples are labeled as "Bad" or "Good".
 In GitLab development guidelines, when presenting the cases, it is recommended
 to follow a **first-bad-then-good** strategy. First demonstrate the "Bad" practice (how things _could_ be done, which is often still working code),
@@ -205,3 +205,8 @@ With many examples being presented, a clear separation helps the reader to go di
 Consider offering an explanation (for example, a comment, a link to a resource, etc.) on why something is bad practice.
 - Better and best cases can be considered part of the good case(s) code block.
 In the same code block, precede each with comments: `# Better` and `# Best`.
+
+NOTE: **Note:**
+While the bad-then-good approach is acceptable for the GitLab development guidelines, do not use it
+for user documentation. For user documentation, use "Do" and "Don't." For example, see the
+[Pajamas Design System](https://design.gitlab.com/content/punctuation).