[UX] Navigation for CDot to represent new User/BillingAccount data structure

## Problem

Right now a Customer record in CustomersDot represents a mixture of a physical user (Zuora Contact) and an Account (Zuora Customer Account). As discussed in https://gitlab.com/groups/gitlab-org/-/epics/8331+, this is a problem for a few reasons, leading to a variety of bugs. The ~"group::fulfillment platform" team is working to correct this by introducing new data models to allow for Accounts and Account Memberships (and renaming Customers to Users to reduce confusion). Multiple Users in CDot should be able to be associated with a BillingAccount. On the flip side, one User record should be able to be associated with multiple BillingAccount (through BillingAccountMemberships).

The UI for CustomersDot currently only supports one User per BillingAccount and one BillingAccount per User. As we work on updating the data structure, we need to think about IA and navigational changes to allow an Account to have multiple billing managers and a User to have multiple BillingAccountMemberships.

## Proposal

Explore how the new data structure will impact the IA and navigation of CDot.

- How/where do Users manage their personal user data vs data associated with an BillingAccount(s)?
- How/where do Users associate additional Customers with an BillingAccount?
- If a User has multiple BillingAccount memberships, how does the choose which BillingAccount they are managing before the normal operations and features are shown, like Managing Purchases or Editing Account information?

While the output of this issue will be the final design/specs of the navigation for a customer with a single BillingAccount only, this issue will also explore, design, and validate navigation for customers with _multiple_ BillingAccounts (because we want to make sure that the navigation will scale to that use case).

### Information architecture

<details><summary>Click to expand</summary>

I wanted to understand how the new User/BillingAccount data architecture and IA will impact CDot navigation. 

:art: [Figma file](https://www.figma.com/file/6eubaRn3G9YP5PmVsHijlr/Navigation-for-CDot-to-represent-new-Customer%2FAccount-data-structure?node-id=0%3A1) for the explorations

#### Process

To start, I did a site map of the current state of CDot. I wanted to understand which information that currently lives under the User model will be moving to the BillingAccount model. Based on information in this [thread](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4799#note_1100958075) and https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4799 and https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4793, I highlighted all affected information/pages in blue. 

![image](/uploads/bf7ceeed3af0db542495d2969e15821c/image.png)

From there, I started reorganizing and grouping the information, making a clearer distinction between what information lives on the User model and what information lives on the BillingAccount model. The team has already ironed out these details as part of spike/exploration work in https://gitlab.com/groups/gitlab-org/-/epics/8331, so this is really just a visualization of that work and thinking through how a user might access it and interact with it.

![image](/uploads/061023388554b5acf03dd127f70ce8da/image.png)

Because it's important to think about the navigation and IA holistically, the site map is based on the end state of https://gitlab.com/groups/gitlab-org/-/epics/8331+. However, I also wanted to think about how this work breaks down and how it fits into the iterations that we've outlined in that Epic. 

I mapped out which parts of the experience would be tackled as part of each iteration (and other key Fulfillment projects like https://gitlab.com/groups/gitlab-org/-/epics/8905+).

![image](/uploads/ea4cd5f8b93442fa5ee5c5ed3d824d8a/image.png)

</details>

### Wireframes

**:clapper: Check out the [video walkthrough](https://youtu.be/pbT0Wn4kWJQ)! (5 1/2 minutes)**

Topics addressed in the video:

* How does the introduction of the BillingAccount impact the *current* information architecture of CDot?
* How will the information architecture change to support the BillingAccount structure?
* What navigation options have been explored to represent that BillingAccount relationship to the user?
* What are the next steps and how can I give feedback?

See [this comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4973#note_1285983310) for more details about the wireframes and how to give feedback.

### Visual designs

Based on the feedback on the wireframes, I explored a variety of different visual designs for the navigation. There were two different designs that moved forward into solution validation.

| Option 1: Dropdown switcher in the left sidebar | Option 2: Account info page header with button to switch Accounts  |
| ------ | ------ |
| ![image](/uploads/58178fbb675257b75fd0542ad5378707/image.png)  | ![image](/uploads/db830f150dd55f4350d26b7e9e0bf12a/image.png) |

### Prototypes

Each of the two visual design options were built out into full prototypes for user testing.

**Important note:** The content and design of many of the pages (such as the My accounts page, the Account details page, and the Billing managers page) is **not final or finished**. There are separate UX issues open to fully design and test these pages. But in order to test the navigation, there needed to be _something_ on those pages, so I threw together quick mockups for the purposes of the user test. 

**Prototype links**
  * [Navigation Option 1](https://www.figma.com/proto/iCqd9J7DOCTS7Q3CDcKdPX/Subscription-management?page-id=33%3A17506&node-id=87%3A27374&viewport=-22%2C1031%2C0.13&scaling=scale-down&starting-point-node-id=87%3A27374&disable-default-keyboard-nav=1&hotspot-hints=0&hide-ui=1)
  * [Navigation Option 2](https://www.figma.com/proto/iCqd9J7DOCTS7Q3CDcKdPX/Subscription-management?page-id=33%3A17506&node-id=125%3A36077&viewport=-20%2C2321%2C0.13&scaling=scale-down&starting-point-node-id=125%3A36077&disable-default-keyboard-nav=1&hotspot-hints=0&hide-ui=1)

### Solution validation 

**:clapper: Want a quick(ish) overview?** I put together an [overview video](https://www.youtube.com/watch?v=Bq4Ywc58ISk) (7 mins) walking through the goals of the research, the prototypes we tested, and the results.

**:book: Want to dig into the findings?** If you're interested in the more detailed insights, check out the solution validation [issue description](https://gitlab.com/gitlab-org/ux-research/-/issues/2149#what-did-we-learn). (You can also find the full research plan and links to the prototypes that we tested in that issue.)

## Final design and specs

#### :arrow_right: :art: [Figma link for final designs and specs](https://www.figma.com/file/iCqd9J7DOCTS7Q3CDcKdPX/Navigation-for-CDot-to-represent-User%2FBillingAccount-data-structure?node-id=265%3A29947&t=pjeyODWa9X6SfD3J-1)

**Important note:** The output of this issue is the final designs/specs for navigation for users with **only a single BillingAccount** (because in https://gitlab.com/groups/gitlab-org/-/epics/8951+, a user will only be able to have a single BillingAccount association).

![image](/uploads/4fb9fbc95c2e54c766b307c964b1a2bd/image.png)

## Follow-ups and next steps

- The design for the navigation for mobile/small screens will be handled in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/6051+
- While the navigation for users with multiple BillingAccounts has already been largely designed and validated in this issue, the final designs and specs will be handled in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4791+

Story points: 5.0