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. We partner closely with our stable counterparts in Product Management and Development.
Each Product Designer is assigned to an area of our product, called Stage Groups. They learn everything they can about users and their workflows to design solutions for real customer problems.
Information about product categories and links to team members and direction pages can be found here.
Some UX teams have documented detailed information about their ways of working and stage groups, and these can be found here:
@gitlab-com/gitlab-ux/ops-ux)
@gitlab-com/gitlab-ux/cicd-ux)@gitlab-com/gitlab-ux/secure-govern-ux)Product Designers follow the guidance outlined in the Product Development flow while working on stage group work with our stable counterparts.
For specific details
Product Designer Tools
Product Design Management
Learning and Development
Are you a new GitLab Product Designer? If so, welcome! Make sure you see the Product Designer Workflow handbook page that will help you get started.
Our design principles can be found with the Pajamas Design System.
In Q4 FY22 and Q1 FY23, we ran an experiment called "Macro UX," in which we paired a Product Designer and an Engineer to make self-directed improvements to a product workflow (Kubernetes Agent). The idea was to empower the pair to make changes they identified themselves and resolved directly with MRs, rather than following our existing Product Development Flow.
The result of the experiment was that the pair was able to resolve low-hanging usability problems, but they ran into challenges when attempting to address larger, more complex problems. However, they did find value in the ability to identify usability problems through heuristic reviews and then quickly partner to fix them. (See the retro issue for details).
In the Beautifying our UI initiative, we'd like to take the best parts of the Macro UX experiment and apply them to making usability improvements in our product.
Going forward, every milestone, we will ask Product Designers and Engineers to volunteer to partner in making self-directed usability improvements. It is an opportunity to fix the things that have been bugging you or that you've heard from users without worrying about prioritization.
/doc directory by the Product Designer or Engineer. Assign the relevant Technical Writer as Reviewer.| Milestone | Product Designer | Engineer |
|---|---|---|
| 15.9 (2023-01-18) | ||
| 15.10 (2023-02-18) | ||
| 15.11 (2023-03-18) | Annabel Gray | Phil Hughes |
| 16.0 (2023-04-18) | ||
| 16.1 (2023-05-18) | Veethika M | Payton Burdette |
| 16.2 (2023-06-18) |
Previous Volunteers
| Milestone | Product Designer | Engineer |
|---|---|---|
| 15.8 (2022-12-18) | - | - |
| 15.7 (2022-11-18) | - | - |
| 15.6 (2022-10-18) | Matej Latin | Deepika Guliani |
| 15.5 (2022-09-18) | Katie Macoy | Anna Vovchenko |
| 15.4 (2022-08-18) | Nadia Sotnikova | Alex Kalderimis |
| 15.3 (2022-07-18) | - | - |
| 15.2 (2022-06-18) | Emily Bauman | Jannik Lehmann |
| 15.1 (2022-05-18) | Sascha Eggenberger | Robert Hunt |
| 15.0 (2022-04-18) | Annabel Gray | Phil Hughes |
If you are a Product Designer or Engineer who wants to volunteer, please create an MR to update the table above by adding your name, and assign it to your manager to review/merge. If you have any questions, please feel free to reach out to the VP of User Experience or the Director of Product Design.
Create an issue, assign it to both Product Designer and Engineer and add it to this epic. Tag the appropriate Product Design Manager and Engineering Manager for awareness. As you progress through the milestone, make sure to link all merge requests to your issue. This will help other stakeholders quickly understand the reason behind the sudden influx of MRs.
You should also keep track of any needed documentation updates. Work with the relevant technical writers to ensure documentation is kept as up-to-date as possible.
Every MR should follow the approval guidelines. If you created an MR, please use the Reviewer Roulette to assign another designer to conduct a UX MR review.
The point of this initiative is to move fast, often in product areas you may not be familiar with. Because these fixes don't go through our regular product development flow, it's important to take reasonable steps to reduce risk. Consider things like:
The team will track total number of MRs merged with the Beautifying our UI label.
The UX Paper Cuts team is a small team responsible for identifying and fixing small, but impactful, usability issues in the GitLab product. The term "paper cut" refers to a small, seemingly insignificant problem that can cause annoyance or frustration for users. When considered as a collective, these problems can reduce the overall impression users have of the product.
The UX Paper Cuts team continuously improves the user experience by creating merge requests to address these small issues. By focusing on small details, the team helps create a more polished and user-friendly interface, leading to increased user satisfaction, engagement, and, ultimately, a more successful product.
You can find changes made by the UX Paper Cuts by following along in the GitLab Polish Gallery, the internal Slack channel #ux_paper_cuts_mrs, or by searching the GitLab label UX Paper Cuts.