Rewrite PD Workflow

| Outcomes | Activities |

|----------|------------|

|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Proposed solution(s) identified and documented**: The DRI works with the team to explore solutions and identifies the approach(es) that strike the best balance of user experience, customer value, business value, and development cost. | The DRI optionally applies the `workflow::ready for design` label to the issue, signaling the design backlog of next issues to be done is prioritized. <br/> <br/> **Diverge**: explore multiple different approaches as a team. Example activities: <br/>- [Think Big](/handbook/product/ux/thinkbig/) session. <br/>Internal interviews (be sure to [document findings in Dovetail](/handbook/product/ux/dovetail/)). <br/> - Creating [user flows](https://careerfoundry.com/en/blog/ux-design/what-are-user-flows/). <br/><br/>  **Converge**: identify a small set of options to validate. Example activities:<br/> - [Think Small](/handbook/product/ux/thinkbig/#think-small) session with the team.<br/> - Design reviews with team<br/> - Low fidelity design ideas. <br/> - Update issue/epic description with proposed solution. Add Figma design file link or attach design to [GitLab's Design Management](https://docs.gitlab.com/ee/user/project/issues/design_management.html) to communicate the solution idea. Read to understand [what tool to use](/handbook/product/ux/product-designer/#delivering-your-solution). <br/> - Validate approach with help from stakeholders. Run user validation using any of the [proposed methods](/handbook/product/ux/ux-research/solution-validation-and-methods/) and [document your findings in Dovetail](/handbook/product/ux/dovetail/) and appropriate GitLab issue. <br/> - Draw inspiration from competitive and adjacent offerings. |

|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Proposed solution(s) identified and documented**: The DRI works with the team to explore solutions and identifies the approach(es) that strike the best balance of user experience, customer value, business value, and development cost. | The DRI optionally applies the `workflow::ready for design` label to the issue, signaling the design backlog of next issues to be done is prioritized. <br/> <br/> **Diverge**: explore multiple different approaches as a team. Example activities: <br/>- [Think Big](/handbook/product/ux/thinkbig/) session. <br/>Internal interviews (be sure to [document findings in Dovetail](/handbook/product/ux/dovetail/)). <br/> - Creating [user flows](https://careerfoundry.com/en/blog/ux-design/what-are-user-flows/). <br/><br/>  **Converge**: identify a small set of options to validate. Example activities:<br/> - [Think Small](/handbook/product/ux/thinkbig/#think-small) session with the team.<br/> - Design reviews with team<br/> - Low fidelity design ideas. <br/> - Update issue/epic description with proposed solution. Add Figma design file link or attach design to [GitLab's Design Management](https://docs.gitlab.com/ee/user/project/issues/design_management.html) to communicate the solution idea. <br/> - Validate approach with help from stakeholders. Run user validation using any of the [proposed methods](/handbook/product/ux/ux-research/solution-validation-and-methods/) and [document your findings in Dovetail](/handbook/product/ux/dovetail/) and appropriate GitLab issue. <br/> - Draw inspiration from competitive and adjacent offerings. |

|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Shared understanding in the team of the proposed solution**: The DRI leads the broader team through a review of the proposed solution(s). | - Review the proposed solution as a team so that everyone has a chance to contribute, ask questions, raise concerns, and suggest alternatives. <br/>- Review the proposed solution with leadership. |

|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Confidence in the technical feasibility**: It's important that Engineering understands the technical feasibility of the solution(s) to avoid rework or significant changes when we start the build phase. | - Discuss the technical implications with Engineering to ensure that what is being proposed is possible within the desired timeframe. When sharing design work, use both Figma's collaboration tools and GitLab's design management features. Read to understand [what tool to use](/handbook/product/ux/product-designer/#delivering-your-solution). <br/>- Engage engineering peers early and often through Slack messages, pings on issues or by scheduling sessions to discuss the proposal.<br>- If the solution is large and complex, consider scheduling a [spike](/handbook/product/product-processes/#spikes) to mitigate risks and uncover the optimal iteration path. |

|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Confidence in the technical feasibility**: It's important that Engineering understands the technical feasibility of the solution(s) to avoid rework or significant changes when we start the build phase. | - Discuss the technical implications with Engineering to ensure that what is being proposed is possible within the desired timeframe. When sharing design work, use both Figma's collaboration tools and GitLab's design management features. <br/>- Engage engineering peers early and often through Slack messages, pings on issues or by scheduling sessions to discuss the proposal.<br>- If the solution is large and complex, consider scheduling a [spike](/handbook/product/product-processes/#spikes) to mitigate risks and uncover the optimal iteration path. |

|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Updated issues/epic descriptions**: The DRI ensures issues and epics are up-to-date. | - Ensure issues and epics are up-to-date, so we can continue our work efficiently and asynchronously. <br/>- [Experiment definition](/handbook/engineering/development/growth/#experimentation). |

|Continue Dogfooding process | - If applicable to their feature, the DRI continues the Dogfooding process by deciding whether to [build the feature in GitLab or keep outside](/handbook/product/product-processes/dogfooding-for-r-d/) the product. |

---

title: Product Designer Priorities and Capacity Management

description: "Here are some guidelines to help Product Designers prioritize their work and manage their capacity at GitLab."

description: "Guidelines for Product Designers to prioritize work and manage capacity as strategic partners working in trios and on platform initiatives."

---

Product Designers work as [managers of one](/handbook/values/#managers-of-one), managing their own capacity across stage group work, platform initiatives, and broader UX responsibilities. This page provides guidance on prioritizing work and planning capacity.

For Product Designers working in [Product Design](/handbook/product/ux/product-design/), part of [Upstream Studios](/handbook/upstream-studios/).

## Planning and managing capacity

Product Designers are assigned to work within their stage group and take on responsibilities across the broader UX department. The following guidelines can assist in effectively managing responsibilities:

- Issues in future milestones (e.g., next release or [Backlog](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&milestone_title=Backlog&label_name%5B%5D=UX)).

- Popular issues with no milestone (based on comments or upvotes).

- [Other issues labeled `UX`](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&label_name%5B%5D=UX).

- [Socializing design work](/handbook/product/ux/product-designer/#socialize-your-work) outside GitLab (blog posts, social media, conferences).

- [Socializing design work](/handbook/product/ux/product-designer/#socializing-your-work) outside GitLab (blog posts, social media, conferences).

#### Supporting Product Management

To aid Product Management in their prioritization efforts, we provide insights into UX needs, identifying both quick wins and larger strategic initiatives.

#### Engagement with Single Engineer Groups (SEGs)

The Engineering Department uses [Single Engineer Groups](/handbook/company/structure/#single-engineer-groups) (SEGs) to quickly develop "new market" initiatives. SEGs may request temporary design support for high-usage product areas.

Product Designers and managers should provide in-depth design critiques in issues and during MR reviews, collaborating with Incubation Engineering to ensure a great user experience.

**Design reviews/critiques**

- SEGs handle their [design ideation](/handbook/product/ux/product-designer/#ideate-and-iterate). Product Designers are not responsible for solving customers problems or creating design assets for SEGs.

- SEGs can request feedback at any phase (early ideations, wireframes, high-fidelity mockups) by contacting the relevant Product Design Manager.

- Ideally, SEGs provide advance notice for design reviews for better planning and capacity management.

**Reviewing SEG merge requests**

- All MRs with user-facing changes require a designer review.

- Treat SEG MRs like [community contributions](/handbook/product/ux/product-designer/mr-reviews/#community-contributions), with the nearest area designer collaborating with the SEG.

- For new product areas without direct stage group impact, use [GitLab Roulette](https://gitlab-org.gitlab.io/gitlab-roulette/) to help assign a Product Designer to an MR for review. Manually spin the wheel to identify the designer.

As strategic partners in trios, Product Designers provide insights into UX needs and help identify both quick wins and larger strategic initiatives. This collaborative approach to prioritization ensures design is involved upstream in planning discussions.

### UX Issue Weights

#### Using UX Issue Weighting

1. Review upcoming issues and break down the work.

1. Assign an issue weight using the provided chart. Collaborate with the Product Manager for clarity if needed.

1. Record your issue weight using your team's preferred method.

    - List issues and weights in Google docs.

1. Review upcoming issues and break down the work

1. Assign an issue weight using the provided chart. Collaborate with the Product Manager for clarity if needed

1. Record your issue weight using your team's preferred method

    - List issues and weights in Google docs

    - Create a linked issue for the UX work and add a weight (close it after completion).

    - Use [design-weight labels](https://gitlab.com/gitlab-org/gitlab/-/labels?utf8=%E2%9C%93&subscribed=&search=design-weight).

1. Communicate your capacity and total issue weights when planning iterations or milestones.

1. Review weights post-milestone to improve future planning accuracy.

    - Use [design-weight labels](https://gitlab.com/gitlab-org/gitlab/-/labels?utf8=%E2%9C%93&subscribed=&search=design-weight)

1. Communicate your capacity and total issue weights when planning iterations or milestones

1. Review weights post-milestone to improve future planning accuracy

**Additional Notes:**

- Most UX issues, including research and Pajamas related issues can be weighted, if desired.

- Consider visual reviews, meetings, and other non-weighted responsibilities when determining capacity.

- Do not weight very small issues (less than 1).

- A weight of 8 or 13 indicates that the issue may be too large.

- Add weights to unplanned work during a milestone and discuss trade-offs with the Product Manager.

- Most UX issues, including research and Pajamas related issues can be weighted, if desired

- Consider visual reviews, meetings, and other non-weighted responsibilities when determining capacity

- Do not weight very small issues (less than 1)

- A weight of 8 or 13 indicates that the issue may be too large

- Add weights to unplanned work during a milestone and discuss trade-offs with the Product Manager

> Milestone Capacity Template:

>

The [UX Department Google Calendar](/handbook/product/ux/operations/#ux-calendar) is the SSOT for UX team meetings and events.

## Design and technical resources

We use [Figma](https://www.figma.com/design/) for designing and prototyping. Our [Pajamas UI kit](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/Pajamas-UI-Kit) contains design assets, components, and styles for GitLab's design system, [Pajamas](https://design.gitlab.com/). Additionally, there is a [Figma plugin](https://www.figma.com/community/plugin/860845891704482356/GitLab) available that allows designers to upload design files directly into a GitLab issue. Every product designer should receive access to Figma during onboarding. If you don't have the access you need, reach out to your manager. If you are not a product designer but want View access (including the ability to leave comments), create a free Figma account and ask your stage group designer for a link to the relevant files.

Figma admins and their role scope are defined as:

|Admin|Scope|

|-----|-----|

|@tauriedavis|Tech stack owner, user management (Provisioning/deprovisioning), billing|

|@vkarnes|Tech stack owner fall back|

|@jeldergl|User management (Provisioning/deprovisioning), design ops|

|@danmh|Design ops|

#### Figjam

We use [Figjam](https://www.figma.com/figjam/) for collecting design feedback, mapping workflows, brainstorming, affinity mapping, and anything else where we need a visual, whiteboard-like workspace.

Everyone in the UX department and all Product Managers can get a Figma account with the ability to create new Figjam boards. If you want to share your Figjam board to get feedback from members of your team who do not have a Figma account, you can send an anonymous link through the Share dialog.

#### AI tools

See [AI usage in UX](/handbook/product/ux/how-we-work/ai-usage/) to learn when to use AI, best practices, what to avoid, and how to keep users at the center while using AI as a helper.

#### Dovetail

We use [Dovetail](https://dovetailapp.com/) to manage and analyze research findings. If you need access, please submit an [Access Request](https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues).

#### Gong

A conversation intelligence tool to record sales facing conversations and provide analytics and insights into those conversations. It can help UX team members identify customers to speak with, or search calls for topics of interest. It is available to UX team members upon request. Create an [access request](https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues) if you would like to use it. You can request the "Collaborator" role.

#### Highspot

Contains information about Go-to-market including sales enablement and competitor research. Highspot can be accessed through SSO and is available upon request. Create an [access request](https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues) if you would like to use it. For more information, see the [Highspot handbook page](/handbook/sales/field-communications/gitlab-highspot/).

### Tutorials