UX Department

The GitLab UX department comprises four areas to support designing the GitLab product: UX Research, Product Design, Technical Writing, and Foundations

Hello!

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

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

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.

  • 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 the UX weekly calls, UX Showcase, 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 Showcases

Our UX Showcase is a fortnightly presentation of notable User Experience projects, where Product Designers from every stage group take turns sharing their accomplishments to collect feedback.

Meet some of our team members


Assessing Category Maturity
We assess the maturity of our product categories based on market evaluations and user testing
Competitor Evaluations
Competitor evaluations help us understand how a competing product addresses the Jobs-To-Be-Done that our product also tries to address.
Design collaborator's playbook
This page acts as a quick reference of mental models for sync and async collaboration.
Documenting research insights in Dovetail
The GitLab UX Research team's guide to documenting insights in Dovetail
GitLab Navigation
The group::foundations team owns the navigation structures of the GitLab product. Please review this information if you plan to propose changes to GitLab navigation.
How to create a user persona
This page goes into detail around the steps needed to create a user persona with a high degree of confidence.
How we work
Jobs to be Done at GitLab
JTBD is a framework for viewing products and solutions in terms of jobs customers want to achieve. It's about understanding the goals that people want to accomplish.
Pajamas Design System
The goal of Pajamas is to be the single source of truth for the robust library of UI components that we use to build the GitLab product
Product Design
We support the business of GitLab by becoming experts in our stage group, educating ourselves about the entire product, and staying engaged with user and business goals
Product Designer Workflow
Here are some guidelines to help Product Designers manage their work at GitLab
Qualtrics tips and tricks
How to use Qualtrics at GitLab to run surveys
Remote Design Sprint
The purpose of a Remote Design Sprint is to create a shared understanding and a solution to a problem following a specific process over a set timeframe. Remote Design Sprint process is based on [Google's Design Sprint methodology](https://designsprintkit.withgoogle.com/methodology/overview), and adjusted using [AJ&Smart's Remote Design Sprint 2.0](https://drive.google.com/file/d/16bwrAqHVf8qxovd87Q7LdzqwAgy7a6Rx/view).
Technical Writing
The GitLab Technical Writing team collaborates with developers, product managers, and the community to develop product documentation. Good documentation meets the evolving needs of GitLab customers, users, and administrators. It educates readers about features and best practices. It enables people to efficiently configure, use, and troubleshoot GitLab. The Technical Writing team manages the docs.gitlab.com site and its content, processes, and tooling. The documentation roadmap drives our efforts to improve both the content and documentation website.
Think Big & Think Small Meetings
The purpose of think big & think small meetings is to develop a shared understanding of goals by discussing vision, roadmap, research, design, and delivery of upcoming features.
UX Department Learning and Development
This page contains links to internal and external resources that members of the UX Department at GitLab can use to build their skills.
UX Department Performance Indicators
Performance indicators for the UX department at GitLab
UX Group Strategy
The UX department stage group strategy pages
UX Heuristics
Heuristics used by the UX team to evaluate our product.
UX Research at GitLab
The goal of UX Research at GitLab is to connect with GitLab users all around the world and gather insight into their behaviors, motivations, and goals.
UX Research Operations Coordination at GitLab
Learn about how UX Research Operations Coordinators work at GitLab
UX Resources
This page includes information about UX Resources to help you do your job as a product desginer at GitLab.
UX Scorecards
The UX Scorecard is a process similar to a heuristic evaluation that helps identify usability issues and score a given experience.
UX Showcase
The UX Showcase is a recurring meeting that allows each stage group to walk through various research findings and design solutions.
Last modified March 21, 2024: Update deferred ux label broken link (8518cae1)