Tech Writing: Create Improved Documentation Template / Information Architecture

We need to create a new golden standard for documentation articles to improve our documentation and allow our users to solve problems by self-serving and easily understanding the content. Documentation at GitLab should have one format and should also include "the why" in addition to other technical information.

Recent updates to the following standards will already drastically improve content, when they are followed for rewrites, edits, and new docs. However, @mikelewis is including notes for context/consideration here, and additional standards here for use/testing during initial revamps.

1. Structure and template doc

   1. @mikelewis updated this doc as part of a discussion with Sid to broaden it to achieve the following:
      1. Update our doc template to be more flexible, since some pages will be specific to a GitLab feature (e.g. Issue Boards), and others will be more specific to a use case (e.g. ‘Use CI/CD to analyze your project’s code quality’) — yet both could be nearly identical in terms of structure/subsections. Docs at both conceptual levels (feature and use case) all need intros, requirements, instruction sets, optional troubleshooting, etc.
         (Previously the template was very prescriptive toward writing about a feature, and I thought we should expand this to cover both features and use cases. I thought this template could cover most docs, without the need for detailed labeling/categorizing of disparate doc types.)
         1. To some extent, talking about types is necessary though, even if the difference is as simple as 'we have feature-based pages (or 'references'), and then workflow-based pages' called Guides or How-Tos; they can exist in parallel with the feature-based pages. A user can find either one, depending on their need (e.g. 'what's this feature?' vs their specific use case need), and each links to the other.
         2. One more type may be a topic-based landing page, for example, a page about Types of Security Testing which is not specific to GitLab features (or at least not a single feature) AND is not a use-case how-to. More of a topic explainer (which of course links to all the other doc types).
   2. Potential additions:
      1. We currently do not account for the fact that there can be features within features; we jump right from Requirements to Instructions sets within our template, as if we're only going to cover a single feature or use case on a page. Do we need a separate template for feature overview pages which shows sub-features and related how-tos?

2. Style guide > Content section

   1. Needs mentions of context: Who is this for (what roles/personas), what are the requirements, etc.

3. Probably beyond the scope of this issue, but we must consider updates to structure at multiple levels: Within docs, among docs in the same section, and across sections. Doc structure across sections is covered here and will need work.

   1. The doc type questions will impact this. E.g. we may restructure into devops stages, and then have parallel folders within the stage folder: topic, guide, feature.
      1. Plan user research e.g. card sorting to help organize.
      2. Gather more metrics on other site improvements (e.g. fixing bugs) to prove we are in a position to focus on building out new content types.
   2. Home page rework to make the site more approachable; easy to see top level sections and what they contain.

4. We need to further update the style standards and templates as we try them, plus the new ideas, and get feedback. We need a way to log this, check in, and decide. For now, this can happen via this issue.