Our UX department is made up of designers, researchers, and technical writers from all around the world. Each of them brings their own unique cultures, experiences, and strengths to GitLab. You can learn about each member of UX by visiting our team page.
The UX Department gets together once a week to share and discuss a variety of topics including workflow shortcuts or processes, designs for feedback, UX articles, and conferences. Attendance is optional but participation is encouraged. Each call is recorded and added to the archive.
The product development timeline that the UX department follows is described in the engineering workflow section of the handbook.
Every Product Designer is aligned with a Product Manager (PM). The UXer is responsible for the same features their PM oversees. The Product Designer meets with their PM, Engineering Managers (EMs), and engineers every month to discuss scheduling and prioritization. Once the milestone has been set, the Product Designer assigns themself to the issues in their area that need UX work. Product Designers should immediately engage in and facilitate a conversation with the PM and engineers involved with the issue. Communicate early and often.
Understanding which PM is responsible for which area of the product is essential. An excellent resource for this is the Product stages, groups, and categories section of the handbook. The Product section of the handbook will give you a deep dive into how Product at GitLab thinks and works.
Milestones (product releases) are one of our planning horizons, where prioritization is a collaboration between Product, Development, UX, and Quality. DRIs for prioritization are based on work type:
We use type labels to track: feature, maintenance, and bug issues and MRs. UX Leadership actively participates in influencing the prioritization of all three work types.
Product Designers continuously leverage the triage process to ensure issues are properly labeled in order to make it easier to identify priority issues.
UX is a stable counterpart when it comes to quad milestone planning. This means that Product Designers and Product Design Managers are active participants in the milestone planning process. Product Designers, with help from their managers, should understand how their Group plans the work for the milestone and should share feedback regularly to influence the issues selected. While UX/Product Design is not a DRI for any of the above work types, they can have a big influence regardless. Here are some examples:
One question that comes up often, is why isn't UX a DRI for a work type. The UX Department's perspective is that our impact is greater as active participants in prioritization of all 3 types (feature, maintenance, bugs) as opposed to advocating for a percentage specific to UX. UX is covered in all 3.
In addition to providing input to priorities during milestone planning, Product Designers also provide input into capacity. A well planned milestone means that everyone understands the requirements and can assess whether or not there is the capacity to complete all of the proposed issues. While we follow the product development timeline, it is recommended that you work with your PM and Development counterparts to discuss upcoming issues in your group's roadmap prior to them being marked as a deliverable for a particular milestone. There will be occasions where priorities shift and changes must be made to milestone deliverables. We should remain flexible and understanding of these situations, while doing our best to make sure these exceptions do not become the rule.
Two tools that help with planning discussions: prioritization sessions and the RICE framework.
If you'd like to learn more about the prioritization process, read through the cross-functional prioritization handbook content.
Before working on the next release, we have a company kickoff call to explain what we expect to ship in the next release. This call is led by the product team and highlights significant improvements and features.
The UX Department is currently investigating a way to perform a UX Team kickoff asynchronously. Kickoff has been postponed until we find a viable solution.
We want to make it as easy as possible for GitLab users to become GitLab contributors. The UX team should offer support, guidance, and resources to any community member interested in contributing code and/or UX improvements.
Issues for which we accept contributions from community contributors are labeled as Seeking community contributions.
We want to encourage our community to contribute at any stage of an issue we are interested in.
If an Seeking community contributions issue has an additional UX ready label, this issue points to changes that:
As a member of the UX Department, make sure to alert your manager if you are asked to work on one of the issues but don’t have the capacity. The manager is responsible for encouraging the community member to suggest a solution, share a design proposal, and keep the conversation going.
For full details on contributing in general, see the contributing doc.
Once assigned to an issue, there is general workflow Product Designers follow.
Read about Product Designer workflows
There is a general workflow UX Researchers follow.
Read about UX Researcher workflows
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
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
While labels are extremely useful for organizing and tracking our work, they are not meant to replace the expertise and judgement of team members, or to replace collaborative touchpoints between PM, UX, and Engineering. Do not rely on labels to communicate important information about an issue (for example, to hand off an issue to a developer). Designers, partnering with PMs and EMs, should determine the best approach for any given problem, and label issues accordingly.
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.
We use epics and issues to organize, discuss, and execute our day-to-day work. Epics are used to define a larger vision and goal for a feature or area of the product. Issues within the epic drive the actions taken to achieve the desired results. In most cases, PM and the Product Design Manager are utilizing epics to plan and execute efforts over several milestones.
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.
The field of User Experience is always changing and evolving. We want Product Designers, UX Researchers, and Technical Writers to have opportunities to stay current on trends and further develop and refine their skills as part of a well-rounded career development plan. To that end, we support participation in relevant and valuable training and conferences, per GitLab's policies.
Your manager will work with the UX Director to communicate and approve requests for professional development.
To attend training or a conference, follow these procedures: