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.
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.
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:
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.
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.workflow::validation backlogworkflow::problem validationworkflow::designworkflow::solution validationThis 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 UX debt. For example, if the agreed MVC design solution is not fully realized due to release pressures or implementation oversight, that's considered UX Debt.
If the design is implemented correctly but unforeseen UX issues are identified, it is not considered UX debt.
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 UX Debt. In case your team makes the decision ship an MVC that contains UX Debt, it is recommended to create an issue to track it as soon as the change has been released.
Learn more about UX Debt as a UX Department Performance Indicator.
SUS::FY22 Q2 - Incomplete.
Learn more about SUS score as a UX Department Performance IndicatorThe 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.
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.
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.