UX Department

Hello

We’re the GitLab User Experience (UX) department. We comprise four areas to support designing and building the GitLab product.

• UX Research
• Technical Writing
• Product Design
• Foundations - Pajamas

Our goal is to make our product easy to use, supportive of contributions from the wider GitLab community, and built for a diverse global community. We want GitLab to be the easiest and most delightful product in its class.

How we work

• We support all users from beginners to experts. We believe that GitLab software should be unintimidating and accessible for a beginner, without oversimplifying important features for advanced users. We stay with users every step of the way to help them learn fast as a beginner and then become an expert over time.
• We’re building one product, together. We’re highly focused on ensuring that no matter how big our product gets, the entire experience stays cohesive, consistent, and interconnected.
• We’re humble facilitators of user experience design. Everyone is a designer; everyone can contribute. We are not egotistical, moody experts who alone hold the keys to user delight. We encourage Product Managers, Engineers, and the wider GitLab community to contribute to creating an exceptional user experience.
• We look for small changes and big impacts. Sometimes the simplest, most boring solution is what is needed to make users successful. We want our UI to stay out of the user’s way. We work iteratively to make modest but valuable changes that make users more productive, faster, and better at accomplishing their tasks.
• We’re informed by empathy. We’re human, and we design for humans, so we strive for understanding, self-awareness, and connection. We are quirky, and we introduce our quirks into designs when appropriate.
• When we find problems that are simple to fix, we are empowered to make those changes ourselves. If a change will take you less than 15 minutes to make (for example, a minor change to our website or microcopy in the product), then start with an MR instead of an issue. By making the change yourself, you are taking immediate action to improve our product, and you might learn a new skill, too! If it seems simple, but you have questions, remember that there are people who can help you with code changes both in the UX department and across the company.

We work closely with the community, and our stable counterparts Product Managers (PM), Frontend engineers (FE), Backend engineers (BE), Quality engineers, and the Brand team. We follow GitLab’s shared process referred to as the Product Development Flow.

• PMs define the “what” and “why” to lead the product direction. These are the benefits we provide to users. It’s informed by gathering customer and user feedback in partnership with UX Research.
• Product Designers define “how” the direction is experienced. It’s how users interact with the product to gain the benefits.
• Engineers define “how” the product is built to meet the product and experience direction from PM and Product Design.

Workflows

• UX Researcher
• Technical Writing
• Product Designer
• Product Design Manager
• Cross-functional Prioritization

Headcount planning

Every Product Designer is aligned with a PM and is responsible for the same customer benefits the PM oversees. Technical Writers each support multiple stage groups. UX Researchers support multiple groups within a section.

In the spirit of having stable counterparts, we plan headcount as follows:

• One Product Designer for every stage group.
  • 1:1 ratio of Product Designers to PM (excludes stage groups with no user-facing impact or, in some cases, stage groups with low usage).
  • 1 Product Designer for 1-3 Frontend engineers; 2 Product Designers for 4-5 Frontend engineers.
• One Technical Writer for up to three stage groups.
  • 1:3 ratio of Technical Writers to stage groups.
  • Approximately a 1:21 ratio of Technical Writers to Engineers.
• One UX Researcher for up to 5 stage groups.
  • 1:5 ratio of UX Researchers to Product Managers.
  • Approximately a 1:35 ratio of UX Researchers to Engineers.
• Manager support that’s appropriate for the function.
  • Approximately a 1:5 ratio of Managers to direct reports for UX Research and Product Design.
  • Approximately a 1:7 ratio of Managers to direct reports for Technical Writing.

UX labels

GitLab uses labels to categorize, prioritize, and track work. The following is a breakdown of the labels most directly related to the UX workflow. An overview of all the label types and uses can be found in the contributing doc.

• UX label: Indicates that UX work is required on this issue. These issues can be new features, ideas for improvement or anything else where UX should contribute their expertise.

• Inclusion label: A change to GitLab that promotes inclusion as it relates to our diversity value.

• Inclusive design label: Considering, exploring, and evaluating the different ways someone would access, interact with, or contribute to content that results in a more accessible experience.

• Accessibility and scoped accessibility labels are used to identify issues with accessibility impact. The scoped labels should be added after an accessibility audit has validated the impact and used in combination with priority and severity labels to triage an issue.

  • Accessibility label: Issues that contain actionable items that help create an accessible product experience.
  • Accessibility-audit label: Issues related to auditing exisiting experiences in order to understand possible accessibility-related improvements.
  • Accessibility-ops label: Issues related to building accessibility into our internal workflows.
  • accessibility::critical: Prevents some or all users from performing critical tasks with no possible workaround.
  • accessibility::high: Prevents some users from performing critical tasks. A workaround may exist, but not without creating frustration and inefficiency.
  • accessibility::medium: Prevents some users from performing non-critical tasks, or where the user experience is seriously degraded for users with certain assistive technologies.
  • accessibility::low: The user experience is degraded for users with certain disabilities or using certain assistive technologies, but users can still accomplish tasks.

• learnability label: Issues that address learnability problems by helping users quickly become familiar with GitLab features.

• Scoped workflow labels from the Product Development Flow should be used to indicate where an issue is in the development lifecycle. Issues can move between workflow labels as many times as necessary, and not all labels will be applicable to every issue. Issues that require UX would use one of these labels as defined in the Product Development Flow:

  • workflow::validation backlog
  • workflow::problem validation
  • workflow::design
  • workflow::solution validation

• Pajamas component lifecycle labels are scoped labels used for creating and updating Pajamas components. Label usage guidelines can be found in the Pajamas component lifecycle documentation.

• UX problem validation label: Indicates that the issue requires UX work to validate that the problem is relevant to users. We use this label in addition to the Product Development Flow scoped labels, so that we can track validation efforts over time in our UX Performance Indicators.

• UX solution validation label: Indicates that the issue requires tasks to validate that the proposed solution is technically feasible and meets user needs. We use this label in addition to the Product Development Flow scoped labels, so that we can track validation efforts over time in our UX Performance Indicators.

• UI polish label: Indicates the issue covers only visual improvement(s) to the existing user interface.

• Deferred UX label: Deferred UX results from the intentional decision to deviate from the UX vision or MVC, which sacrifices the user experience. Deferred UX labeled issues are to be included in subsequent releases. Use this label to indicate that the UX released does not meet:

  • UX and Pajamas specifications
  • Usability standards
  • Feature viability standards

  This label is applied to any follow-up issues that address a UX gap. It does not apply to the issue or merge request that created the Deferred UX. For example, if the agreed MVC design solution is not fully realized due to release pressures or implementation oversight, that’s considered Deferred UX.

  If the design is implemented correctly but unforeseen UX issues are identified, it is not considered Deferred UX.

  If in doubt about when to apply this label, use the following rule: If you can say “This UX problem did not originate from an issue or merge request,” then it’s just UX, not Deferred UX. In case your team makes the decision ship an MVC that contains Deferred UX, it is recommended to create an issue to track it as soon as the change has been released.

• Learn more about Deferred UX as a UX Department Performance Indicator.

• UX Paper Cuts label: Used to prioritize and track work from the UX Paper Cuts team.

• Seeking community contributions

• System Usability Scale (SUS) labels: Indicates that the issue is related to usability problems surfaced in one of our SUS research efforts. More specifically, issues related to SUS that are prioritized can be labeled with the corresponding Fiscal Year and Quarter. For example: SUS::FY22 Q2 - Incomplete. Learn more about SUS score as a UX Department Performance Indicator

• Regression label: Indicates a bug introduced in the latest release that broke correct behavior (see the contribution guidelines for more info).

• UX scorecard label: Indicates the primary issue or epic for the UX Scorecard. We use this label to help us easily find current work and track efforts over time.

• UX scorecard-rec label: Indicates this issue is a recommendation that was a result of a UX scorecard review. It’s OK if the issue was created prior to the scorecard being done; it can still be pulled into the set of recommendations.

• CM scorecard label: Indicates the primary issue or epic for the CM Scorecard. It is used to easily find current work and track efforts.

• cm-scorecard-rec label: Indicates this issue is a recommendation that was a result of a CM Scorecard.

• Actionable Insights document learnings from research that need to be acted on.

  • Actionable Insight::Exploration needed: A research insight derived from a UX research study that requires further exploration.
  • Actionable Insight::Product change: A research insight derived from a UX research study and requires a change to the product experience.

• Type labels: Used to track feature, maintenance, and bug issues and MRs. UX Leadership are active participants in influencing the prioritization of all three work types. See also who are the DRIs for prioritization.

• Theme labels can be created to group issues that solve a similar user experience problem but don’t have a category. This can be especially useful for a user experience that spans the product. These issues still require a UX label.

• UX: Feature Discovery Improvement: Indicates issue may improve feature discoverability.

• UX: Onboarding Improvement: Indicates issue is a potential onboarding improvement.

UX Calendar

The UX Calendar (internal only) is the SSOT for our team meetings. You can find the details for UX calls, UX Forum, and other team meetings here. These meetings are open to everyone in GitLab. Anyone in the UX department can add events to the Google Calendar. Managers and above can make changes and manage sharing, while ICs can make changes to events. Please reach out in the #ux_leadership Slack channel with any questions or requests.

Retrospectives

After each release, we have a company retrospective call in which we discuss what went well, what went wrong, and what we can improve for the next release.

To understand the specific challenges faced by the UX Department, we hold an async UX retrospective after every milestone. This retro is carried out through a new Issue created for the recent release in the ux-retrospectives project. The goal is to evaluate what went well, what didn’t go well, and how we can improve.

UX Forum

The UX Forum is a recurring meeting for UX team members to share and discuss their work. This includes past, current, or future work, and covers Product Design, UX Research, and Technical Writing. All meetings are recorded and made available on Unfiltered for Product, UX, Engineering, and Leadership to watch at their convenience.

UX Talent Assessment

In UX, we utilize performance factor worksheets (🔒 internal only) as a way to facilitate talent assessment and growth conversations between manager and their direct reports. These worksheets are available in Google Sheets format and the spreadsheets include tabs for a mid-year and year-end review, as well as a tab to list Achievement, Strengths, and Opportunities throughout the year.

It is strongly encouraged for each team member to have their own worksheet created at the start of the fiscal year so that it can be used as a tool throughout the entire year.

Meet some of our team members

• Valerie Karnes - Director of Product Design
• Jacki Bauer - Product Design Manager
• Justin Mandell - Product Design Manager
• Taurie Davis - Senior Product Design Manager
• Rayana Verissimo - Product Design Manager
• Jeremy Elder - Staff Product Designer, Foundations
• Austin Regnery - Senior Product Designer
• Anne Lasch - Senior UX Researcher
• Emily Bauman - Senior Product Designer
• Will Leidheiser - Staff UX Researcher

View page source - Edit this page - please contribute.