The mission of the GitLab UX team is simple, to make a software product that is easy to use and enables everyone to contribute. We are building GitLab for a diverse, global community. It is essential to understand that community; it’s behaviors, needs, and motivations. We believe in iterative improvements and value aggressive change. We will get some things wrong and quickly strive to make them right. We have a long way to go, that is why we are taking big steps.
We have four guiding values that drive our UX work. GitLab should be professional and productive, human and quirky, minimal and efficient, and immediately recognizable. You can learn about these values in detail on design.gitlab.com.
Our UX team is made up of designers and researchers from all around the world. Each of them brings their own unique cultures, experiences, and strengths to GitLab. You can learn about each team member by visiting our team page and filtering by "UX".
The UX team 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 UX team works alongside the community, Product Managers (PMs), Frontend engineers (FE), and Backend engineers (BE). PMs are responsible for kicking-off initiatives, taking action, and setting the direction of the product. PMs don't own the product, they gather feedback and give team members and the community the space to suggest and create. UX should help drive and inform that vision as soon in the process as possible. We do this by conducting research as well as facilitating discussion with community members, PM, FE, and BE.
The product development timeline is described in the engineering workflow section of the handbook. We will also explain it here.
At GitLab we follow a monthly release cycle, shipping on the 22nd of each month. We plan and track these monthly releases using milestones.
There are specific deadlines that inform team workflows and prioritization. Suppose we are talking about milestone
m that will be shipped in month
M (on the 22nd). We have the following deadlines:
missues are updated with docs starter blurb. Release post (WIP merge request) created with
missues and docs starter blurbs.
M-1, 8th(or next business day): Kickoff call
M, 7th: Completed
missues with docs have been merged into master. Un-started or unfinished
missues are de-scoped from
mbeing removed from them.
M, 15th: team retrospectives should happen so they can inform the public retrospective
M, 22nd: Release shipped to production. Release post published.
M 22nd: The next Release has been tentatively planned by Product and has been shared with engineering for discussion.
Our release timelines are overlapping. For example, when a release is shipped to production on the 22nd, the scope for the following release has already been established earlier in that same month. The following visualization illustrates that overlapping concept.
Between the 22nd and 1st of each month, the UX Manager meets with PMs and other Engineering managers to discuss the priorities for the upcoming milestone. The purpose of these meetings is to ensure that all understand the requirements and to assess whether or not there is the capacity to complete all the issues proposed. The issues set for a particular milestone must be decided by the 1st of each month to give the engineering teams time to plan. There will be occasions where priorities shift, and changes must be made after the 1st. We should remain flexible and understanding of these situations while doing our best to make sure these exceptions do not become the rule.
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 team has its kickoff as part of the UX weekly call directly preceding or following kickoff on the 8th of the month. Using the planning sheet as our guide, each designer walks through the issues they will be working on for that milestone. The kickoff fosters transparency and collaboration across the whole team so it is important that all UXers attend.
Every UX Designer is aligned with a PM. The UXer is responsible for the same features their PM oversees. UXers work alongside PM at each stage of the process. Planning, discovery, implementation, and further iteration. The area a UXer is responsible for is part of their title, e.g. "UX Designer, Platform." You can see which area of the product each UX Designer is aligned with in the team org chart.
UXers may also serve as a "backup" designer for other areas of the product. This area will be listed on the team org chart under their title as an expertise, e.g. "Platform expert."
The UX Designer meets with PMs and other engineers every month to discuss scheduling and prioritization. Once the milestone has been set, the UXer assigns themselves to the issues in their area that need UX. UXers 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 who to talk to for what and product categories sections of the handbook. The product section of the handbook will give you a deep dive into how product at GitLab thinks and works.
Once assigned to an issue, there is general workflow UX Designers follow. This workflow is detailed in the UX Designer section of the handbook.
There is a general workflow UX Researchers follow. This workflow is detailed in the UX Research section of the handbook.
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 workflow label types and uses can be found in the contributing doc.
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 team, we hold an async UX retrospective after every milestone. This retro is done within the planning document. 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 UX Manager are utilizing epics to plan and execute efforts over several milestones.
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 that are beneficial to our users, 'nice to have(s),' that we currently do not have the capacity for or want to give priority to are labeled as Accepting Merge Requests so that the community can contribute. Community contributors can submit merge requests for any issue they want, but the Accepting Merge Requests label has a special meaning. It points to changes that:
We want to avoid a situation where a contributor picks an Accepting Merge Requests issue, and then their merge request gets closed because we realize that it does not fit our vision, or we want to solve it differently.
As a member of the UX team, make sure to alert the UX Manager if you are asked to work on one of the issues but don’t have the capacity. The UX 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 Accepting Merge Requests and contributing in general, see the contributing doc.
The GitLab Design System was developed to increase iteration speed and bring consistency to the UI through the creation of reusable and robust components. This system helps keep the application DRY and allows designers to focus their efforts on solving user needs, rather than recreating elements and reinventing solutions. It also empowers Product, engineering, and the community to use these defined patterns when proposing solutions. The Design System can be viewed at design.gitlab.com. It is currently a work in progress.
The project and repository for design.gitlab.com can be found here.
Our GitLab SVGs repository manages all SVG assets by creating an SVG sprite out of icons and optimizing SVG based illustrations.
All of our SVGs can be previewed using this URL
The UX research project contains all research undertaken by GitLab's UX researchers. This project is used for the organization and tracking of UX research issues only.
The UX design archive is a collection of key design issues broken down by specific areas of GitLab. It is not a comprehensive list. It is intended to shed insight into key UX design decisions.
The UX research archive is a collection of UX Research broken down by specific areas of GitLab. It is intended to shed insight into key UX design decisions and the data that informed those decisions.
It is encouraged to share UX designs and insight on social media platforms such as Twitter and Dribbble.
GitLab has a Dribbble team account where you can add work in progress, coming soon, and recently released works.