refactor: Add usability collection page

What does this MR do?

This MR

• Add collection page for /usability
• Add initial summary content to support linking in !4012

This MR follows on from discussion in !4058 (closed).

Context

• The first collection page (components overview) was added 3 years ago in !2517 (merged) with the goal to "have a components overview page that included cards with visuals for each component. This helps decipher which component to use solely based on the visual provided […] without knowing the use cases for each […] you'd have to go into each to determine which component you should use for your use case."
  • Adding the visuals is yet to happen. But perhaps we are closer now many more components have a structure image.
• We link to the components overview in two places when we want to talk about components generally, rather than commit to an individual component. I'm not sure if it would make sense to link to the first component in the list, accordion, in these instances.
• Today "the brand guidelines get the highest amount of traffic on the Pajamas site and the team feels they'd benefit from more exposure" #1899.

Based on this, here's how I'd describe the goals of the collection pages:

• Provide a destination when it makes sense to link to a section of design.gitlab.com where there is no existing overview page. For example when wanting to link to all patterns.
• Allow readers to compare items within a sub-section when the title alone does not give enough information.

The goal is not to create new items for inclusion in the left sidebar navigation.

Here's Jeremy's own words to describe this

These pages are intentionally not revealed in the navigation and only serve as a "collection" of the content pages within a certain section. This enables us to have links from the homepage, and elsewhere that can reference a set of content without needing to provide an overview page. For example, see this draft MR (!4012) that has lead-ins linking to a page like these. On the note of "overview," this concept is still used and exposed in the navigation when it's helpful for decision making or to provide higher-level context, whereas collection pages are only a group of related links with descriptions.

Collection pages are designed to:

• Provide a destination when it makes sense to link to a section of design.gitlab.com where there is no existing overview page. For example when wanting to link to all patterns.
• Allow readers to compare items within a sub-section when the title alone does not give enough information.

Plan

This MR is part of a larger series of changes to broaden the scope, and improve navigation and discovery of design.gitlab.com.

• Create collection page component !4085 (merged)
• Create collection page for /content/ !4088 (merged)
• Create collection page for /patterns/ !4089 (merged)
• Create collection page for /product-foundations !4101 (merged)
• Create collection page for /usability👈 THIS MR
• Create collection page for /objects
• Create collection page for /data-visualization
• Create collection page for /usability

Does this MR meet the acceptance criteria?

• The MR title and commit messages meet the Pajamas commit conventions.
• The “What does this MR do?” section in the MR description is filled out, explaining the reasons for and scope of the proposed changes, per “Say why not just what”.
  • For example, if the MR is focused on usage guidelines, addressing accessibility challenges could be added in a separate MR.
• Relevant label(s) are applied to the MR.
• The MR is added to a milestone.
• If creating a new component page from scratch, it follows the page template structure.
• Content follows the Pajamas voice and tone guidelines, falling back on the GitLab Documentation Style Guide when needed.
• Related pages are cross-linked, where helpful. Component pages have related components and patterns defined in their Markdown front matter.
• If embedding a Figma file, it follows the Figma embed guide.
• Review requested from any GitLab designer or directly from a maintainer or trainee maintainer.
• Maintainer review follows the Pajamas UX maintainer review checklist.

Links