1. You are here:
2. Handbook
3. Product Handbook
4. UX Department
5. Product Design
6. Product Design Manager Workflows

On this page

• Product Design Manager Workflows
  • Requesting a borrow
  • Team Skills Matrix
    • How to conduct the team assessment
    • Definitions
      • Levels
      • Skills
  • Team Member Updates
    • Section-level updates
    • Group-level updates
    • Name confirmation
    • Update Team Member (Such as to remove/add from UX MR Reviewer Roulette)
    • Triage reports
    • Retrospectives

Product Design Manager Workflows

Requesting a borrow

A borrow is used when a team member is shifted from one team to another temporarily or assisting other teams part-time for an agreed-upon period of time.

There are two Borrow request options. Choose the one that makes the most sense for your situation.

• If multiple members (within or including outside of UX) are part of the borrow request, use the Borrow issue template.
• If a borrow is limited to a single member of UX (such as a Product Designer) and no other stable counterparts, use the Borrow Lite issue template.

Before a borrow takes place, make sure to have it approved by the appropriate director (Product Design, UX Research, or Technical Writing).

Utilizing these issues will help us understand the frequency and duration of borrows throughout the year. Tracking occurs by appending the UX Borrow label to each issue request.

Team Skills Matrix

We conduct an annual team skills analysis based on a process recommended by Nielsen-Norman.

This allows us to see our strengths as a team and to identify team trainings that would benefit a large portion of the team, help us identify strengths we'd like to add when hiring new team members, and inform individual team member's growth plans. It can also act as a resource for matching mentors and/or design pairs.

How to conduct the team assessment

1. Make a copy of the GitLab focused template (private to GitLab).
2. Review the template to make sure it still makes sense for your team. Do consider changes carefully and discuss with other managers. We want to be able to have consistency in these so we can view them across multiple design teams.
3. Introduce this process to your team by sharing this page, the NN article and the GitLab focused template.
4. Copy the template for each individual team member and share it with them.
5. In 1:1s, have a casual conversation with the team member and ask them to rate themselves in their individual file. You may suggest adjustments based on your observations - if you do, share an example of why.
6. After completed the assessment with each team member, copy the results to the main team template. I kept this file private.
7. Create an issue similar to #1674 to share the results. You can remove individual names from this view.
8. Have a retrospective with your team to identify strengths and weaknesses. Find things to build up the weaknesses (where people have said they want to improve).
9. Share with other UX leaders.

Definitions

Note: These are also in the template, which is the SSOT.

Levels

1. Awareness: You are aware of the competency but are unable to perform tasks.
2. Capable but still new to the skill: You understand the concept and you can apply it but your experience is limited (you might be new to GitLab or new to quant research for example).
3. Intermediate proficiency: You have applied this skill to situations occasionally without needing guidance.
4. Advanced proficiency: You regularly apply this skill at an advanced level without needing guidance.
5. Advanced proficiency + leader: You can coach others in the application by explaining related nuances.
6. Expert: You have demonstrated consistent excellence across multiple projects and are a thought leader across the UX department.

Skills

• Qualitative research: Usability testing, interviewing. Creating effective unbiased research plans. Synthesizing data into insigts.
• Quantitative research: Understanding when to use surveys and how to use the data, AB testing - when to use and what do do the data, how to design for an experiment.
• Visual design - UI design, graphic design, illustrations, typography, logos.
• Interaction design - Form and flow design, micro-interactions, handling latency and error states, UI copy, page layout.
• Leadership: Starting new issues, being a content or design contributor (handbook, Pajamas, YouTube, etc), collaborating with others to acheive big goals, evangelizing your teams outcomes or sharing new methods or skills.
• Iteration: Every MVC is an iteration. Every iteration should be an MVC. Additionally, includes breaking projects down into parts to get results faster - could be smaller studies, smaller design scope. Not refining design work too early, not going too far into the work before circling back for feedback.
• Design communication: Sync or async, the ability to see and quickly understand a design, critique it, share design rationale for the design, get feedback from the right people at the right time.
• IA and Workflow Definition: Organizing large amounts of data or concepts, navigation design, card sort, and tree studies, creating workflow diagrams and screen flows.

Team Member Updates

Whenever you need to update the area of the product a team member is supporting, such as on the Product Categories page, you'll generally need to update or review the following pages and projects:

Section-level updates

For section-level updates you'll want to do the following:

1. Go to the www-gitlab-com project > Repository > Files
2. Select the data directory
3. Scroll down and click on the sections.yml file
4. Select the editor type of your choice
5. Locate the person you need to update, make the change, commit/create an MR, and follow the MR process from there

Group-level updates

For group-level updates you'll want to do the following:

1. Go to the www-gitlab-com project > Repository > Files
2. Select the data directory
3. Scroll down and click on the stages.yml file
4. Select the editor type of your choice
5. Locate the person you need to update, make the change, commit/create an MR, and follow the MR process from there

Name confirmation

For all updates you'll want to confirm that the person you've updated has a name reference in the category names file, otherwise it won't render correctly on the handbook page it's being called on.

1. Go to the www-gitlab-com project > Repository > Files
2. Select the sites directory
3. Select the handbook directory
4. Select the source directory
5. Select the includes directory
6. Select the product directory
7. Scroll down and click on the _categories-names.erb file
8. Select the editor type of your choice
9. Locate the person you need to update, make the change, commit/create an MR, and follow the MR process from there
   • Note: If a team member is going to be performing Interim duties you’ll need to add their name a second time following this format: [fName lName (Interim)]: /company/team/#GitLab-username

Update Team Member (Such as to remove/add from UX MR Reviewer Roulette)

Go to the www-gitlab-com project > Repository > Files

1. Select the data directory
2. Select the team_members directory
3. Select the person directory
4. Locate the correct alphabet letter folder according to the team members first initial in their first name
5. Click on their .yml file
6. Select the editor type of your choice
7. To remove from the UX MR Reviewer Roulette bot:
   1. Delete the gitlab: reviewer UX line under the projects: section
   2. Commit/create an MR, and follow the MR process from there
8. To add to the UX MR Reviewer Roulette bot:
   1. Revert the original MR where the team member was removed or
   2. Find their .yml file again following the above steps
   3. Add back the gitlab: reviewer UX line under the projects: section
   4. Commit/create an MR, and follow the MR process from there

Triage reports

In the triage-ops project, open an MR to add or remove team members from receiving triage reports. The file to edit is group_definition.yml.

Retrospectives

In the GitLab team retrospective group, find the team members section and group, and add and remove team members there. This step is required so that confidential issues can be seen by team members.

Also, open an MR to add or remove team members in the team.yml file in async-retrospectives.