Product Design migration (B): Add workflow pages to Upstream Studios

### Company handbook

At GitLab, we believe that "everyone can contribute." The company handbook is where everything is documented — our [single source of truth](../handbook-first/#terminology-documentation-handbook-first-single-source-of-truth) — specifically laying out the six core [values](/handbook/values/) of the company. The handbook deliberately and intentionally describes each group's role within the company, including how the [UX teams](/handbook/product/ux/product-designer/) researches, designs and writes about the product.

At GitLab, we believe that "everyone can contribute." The company handbook is where everything is documented — our [single source of truth](../handbook-first/#terminology-documentation-handbook-first-single-source-of-truth) — specifically laying out the six core [values](/handbook/values/) of the company. The handbook deliberately and intentionally describes each group's role within the company, including how the [Upstream Studios teams](/handbook/upstream-studios/product-design/workflow/) researches, designs and writes about the product.

### Iterate and iterate some more

#### How we work

- We follow the [Product Designer workflows](/handbook/product/ux/product-designer/) and [UX Researcher workflows](/handbook/upstream-studios/experience-research/) described in the [Product Design section](/handbook/product/ux/) of the handbook.

- We follow the [Product Designer workflows](/handbook/upstream-studios/product-design/workflow/) and [UX Researcher workflows](/handbook/upstream-studios/experience-research/) described in the [Product Design section](/handbook/product/ux/) of the handbook.

- We measure our progress using [UX Scorecards](/handbook/product/ux/ux-scorecards/).

- We prioritize the most important projects every quarter, and Fulfillment product designers [support projects instead of Groups](#product-designer-focus-areas).

- We use [[UX] issues](#ux-issue-management-and-weights) as the SSOT for designs. Implementation issues should link to the [UX] issue for the design details to maintain the SSOT.

- To manage workload, designers should generally be assigned to no more than one large and 1 small/medium project at a time, or 3-4 small/medium projects (or the equivalent in issue weights).

- Designers should use their best judgement and collaborate with their teams to decide which meetings to attend. Designers aren't expected to attend team sync meetings for multiple teams at the same time.

- Product Designers should be assigned [UX MR reviews](/handbook/product/ux/product-designer/mr-reviews/) for the projects they're supporting.

- Product Designers should be assigned [UX MR reviews](/handbook/upstream-studios/product-design/workflow/mr-reviews/) for the projects they're supporting.

  - If UX review is needed on an MR that is part of a project without an assigned designer, post the request in the #s_fulfillment_ux Slack channel. UX MR review requests in the Slack channel will be picked up based on bandwidth.

#### UX issue management and weights

1. Security-related issues (such as changes to authentication) require a [Security review](/handbook/security/product-security/security-platforms-architecture/application-security/appsec-reviews/#adding-features-to-the-queue--requesting-a-security-review)

1. Changes to the SFDC APIs require review by the [Sales team](/handbook/sales/field-operations/sales-systems/)

1. Changes to the Zuora APIs require review by the [EntApps team](/handbook/business-technology/enterprise-applications/)

1. Changes to the user experience require a [UX Review](/handbook/product/ux/product-designer/mr-reviews/).

1. Changes to the user experience require a [UX Review](/handbook/upstream-studios/product-design/workflow/mr-reviews/).

### Weekly async issue updates

### Workflow

Unless specifically mentioned below, the Software Supply Chain Security:Pipeline Security group follows the standard [engineering](/handbook/engineering/workflow/), [product](/handbook/product-development/how-we-work/product-development-flow/), and [UX](/handbook/product/ux/product-designer/) workflows.

Unless specifically mentioned below, the Software Supply Chain Security:Pipeline Security group follows the standard [engineering](/handbook/engineering/workflow/), [product](/handbook/product-development/how-we-work/product-development-flow/), and [product design](/handbook/upstream-studios/product-design/workflow/) workflows.

#### Starting New Work

All issues worked on by a designer should have a UX weight before work is scheduled for a milestone.

- Issue weights should follow the [UX Department's definitions](/handbook/product/ux/product-designer/capacity-management/#ux-issue-weights).

- Issue weights should follow the [Upstream Studios Department's definitions](/handbook/upstream-studios/product-design/workflow/capacity-management/#ux-issue-weights).

- If the issue is a dedicated [UX] issue, then the issue weight can be added to the `weight` field, but it should also be duplicated as a ~'design weight:" label. This is for UX Department planning purposes. For smaller issues where implementation and UX work happen in the same issue, UX weight should be added using the ~'design weight:" label (the `weight` field is used by engineering).

- Product Managers and Product Designers can use issue weights to ensure the milestone has the right amount of work, to discuss tradeoffs, or to initiate conversations about breaking work into smaller pieces for high-weight items.

Product Designers play a critical role in the product development of user-facing issues. They collaborate with the Engineering and the Product Manager to design the user experience for the features. Once the design solution is proposed, agreed and validated, the Engineering [DRI](/handbook/people-group/directly-responsible-individuals/) is assigned to implement that design and functionality during the milestone for which the issue is planned.

Following the [code review guidelines](https://docs.gitlab.com/ee/development/code_review.html#approval-guidelines) means that we should ensure all MRs with user facing changes are reviewed by a product designer. UX reviews should follow [the designer review guidelines](/handbook/product/ux/product-designer/mr-reviews/) as closely as possible to reduce the impact on velocity while maintaining quality.

Following the [code review guidelines](https://docs.gitlab.com/ee/development/code_review.html#approval-guidelines) means that we should ensure all MRs with user facing changes are reviewed by a product designer. UX reviews should follow [the designer review guidelines](/handbook/upstream-studios/product-design/workflow/mr-reviews/) as closely as possible to reduce the impact on velocity while maintaining quality.

#### Inclusive Development