Merge branch 'rayana-master-patch-20489' into 'master'

Adds pair designing guidelines to UX Handbook

See merge request !42438

source/handbook/engineering/ux/how-we-work/index.html.md

@@ -43,6 +43,7 @@ The UX department is not solely responsible for the user experience of GitLab. E
 If you are creating high-fidelity designs, please make sure to let others know that this is a proposal and needs UX review. You can ping anyone on the UX team for assistance.
 
 ## Proactive and reactive UX
+
 We'll always have responsibility for reactive tasks that help "keep the lights on," such as bug fixes and minor UX enhancements. But we also must carve out some portion of our time for proactive work that identifies existing pain points, redefines how we approach problems, and uncovers actionable innovation and improvement opportunities. This proactive UX work enables us to create the most complete, competitive, and resilient solutions. 
 
 It isn’t always easy to find the space for proactive UX work, but the challenge is worth it, because it's how we create a best-in-class product experience. And it's not just the UX team's responsibility; it requires a coordinated effort from Leadership, Product, and Engineering, too.
@@ -50,6 +51,7 @@ It isn’t always easy to find the space for proactive UX work, but the challeng
 We're currently working to find the right balance between proactive and reactive UX work. While we don't have a prescriptive ratio, we also don't allot 100% of our available work time to reactive efforts. Before and at the start of each milestone, UXers should work with their managers to define the appropriate ratio, based on our active OKRs and stage group requirements. When there are questions about priority or scope, or when a UXer is concerned about meeting a deadline, they should immediately reach out to their manager to help them resolve any concerns. Comunicate early and often!
 
 ### Examples of proactive UX
+
 One example of proactive UX work is our [UX Scorecards](/handbook/engineering/ux/ux-scorecards/) initiative. Another example is the generative research that our UX Researchers lead (while inviting cross-functional partners to participate). Yet another example is the ongoing effort to beautify our UI, both through [small, tactical changes](https://gitlab.com/groups/gitlab-org/-/epics/989) and through our [Pajamas Design System][pajamas].
 
 **UX Scorecards** <br>
@@ -67,7 +69,17 @@ Iteration is especially vital in an open-source community. Keeping changes small
 * We keep a list of improvement issues that are actively seeking contributions from the community. They are small in scope, allowing the community to contribute designs or code to the issues. You can learn more about it in the [Community Contributions](/handbook/engineering/ux/ux-department-workflow/#community-contributions) section of this handbook. You can also [view the list of issues that need UX work](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&label_name[]=Accepting+merge+requests&label_name[]=UX).
 * You may notice that our [Design System](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com) has a lot of "to-do" items. Rather than try to tackle everything at once, we are gradually populating our component library and incrementally rolling those components out to production.
 
+## Pair Designing
+
+Pair Designing gives Product Designers a consistent partner to ideate with at the beginning of an effort and get feedback from during the design process and conduct [design reviews](/handbook/engineering/ux/ux-designer/#design-reviews). It also gives UX Designers exposure to product areas outside of their own.
+
+* Every six months, product designers are assigned to a new pair designer from a different stage group.
+* If we have an odd number of UXers, we'll have one 3-person partnership.
+* Pairs decide what to share and when; there is no pre-defined schedule or guidelines.
+* It’s imperative to explicitly ask for feedback and give context.
+
 ## Stable counterparts
+
 Every Product Designer is aligned with a PM and is responsible for the same features their PM oversees.
 Technical Writers each support multiple stage groups and at least one complete stage (up to four) with the goal of supporting only one stage per writer by the end of FY-2020 per the current hiring plan. UX Researchers support multiple PMs from across one or more sections.