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 Design at GitLab

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.

Process and DRI

Owner of design judgment

As Product Designers, we are the owners of design judgment.

We start with a problem to solve and always first consider what the best experience for the user would be.

If we get additional information about constraints or context from counterparts (e.g. technical considerations or a marketing advantage), we take that as input and evaluate together if and how we need to adapt our designs. When these constraints have influenced our design proposal, we communicate proactively about the fact that these constraints exist, how they changed the design, and what impact these changes will have on the user.

If our counterparts have a different opinion on what will serve the user best, we evaluate if that’s correct and how it will change our design, but we are empowered to make the final call on this question, as we are the owners of design judgment.

Identifying UX needs to aid Product Management prioritization

To support the Product Management team with their prioritization, we give them our input for UX needs. This could be both for quick wins, as well as for larger strategic initiatives.

Design

Our design principles can be found with the Pajamas Design System.

Team Structure

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.

UX Paper Cuts Team

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 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.

Learn more about UX Paper Cuts

Learn about UX and see our work

Product Design Workflow

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.

Design Principles

Our design principles can be found with the Pajamas Design System.

Cross-functional Initiatives

Beautifying our UI

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.

Next steps

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.

  • Self-Directed: There are no restrictions on where in the product the pair can make improvements. The goal is to empower the pair to focus on usability improvements that they personally want to see fixed in a product that they use themselves almost every day.
  • No restrictions on product area: The pair is not required to work within product areas owned by their own stage groups. That does mean you need to ask questions to assess impact when making significant changes to a product area you don’t know well.
  • No restrictions on pairings: The Product Designer and Engineer pair do not need to be from the same stage group. This is a voluntary initiative.
  • Work in MRs, not issues: Both the Product Designer and the Engineer should work directly in MRs to make changes. For the Product Designer, these MRs will likely be focused on less complex usability issues that the pair identifies, such as documentation, minor UI polish, or UI text changes. To make it easier for others to understand the change, make sure that you add screenshots and explain what was changed and why (unless it’s an obvious bug fix) in the MR description.
  • Length of rotation: The length of the pairing will be 1-3 milestones, depending on what the pairing believes is appropriate for them. This means that multiple groups could be working on Beautifying our UI in parallel.
  • Prioritization: The Product Designer and Engineer will inform their direct managers and discuss prioritization and capacity planning prior of their involvement in the initiative, so that they can make time for it during milestone planning. They’ll make sure their stage group team is also aware of their involvement.
  • Documentation: UI changes can impact the documentation to varying extents. The Product Designer or Engineer will follow the Definition of Done, with any docs changes required documented in the /doc directory by the Product Designer or Engineer. Assign the relevant Technical Writer as Reviewer.

Volunteers

Milestone Product Designer Engineer
16.8 Veethika Mishra Mireya Andres
17.0
17.1 Veethika Mishra Miguel Rincon
17.2
17.3
Previous Volunteers
Milestone Product Designer Engineer
16.1 (2023-05-18) Veethika M Payton Burdette
15.11 (2023-03-18) Annabel Gray Phil Hughes
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.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

How do I volunteer?

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. In the MR description, please include what percentage of your capacity you plan to dedicate to this initiative. If you have any questions, please feel free to reach out to the VP of User Experience or the Director of Product Design.

I signed up. Great! What’s next?

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.

Remember to assess the possible impact of your changes

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:

  • Use feature flags. To more quickly and easily revert changes, it can make sense to use feature flags. Annabel Dunstone Gray recorded a UX showcase around how to do so and why it might be beneficial.
  • How will this change impact our self-managed customers? Because we use our SaaS product, we’re not always personally aware of nuanced differences between our Self-Managed and SaaS offerings. Make sure to consider the possible implications of any changes to all of our deployment options. Start by reviewing the docs related to the feature, and ask questions if you’re still unsure.
  • How can I crowd source feedback on a significant change? Sometimes there will be dependencies that aren’t obvious. Consider opening up feedback issues (like this one) and use our internal Slack to make the company aware of significant upcoming changes, so that people can offer feedback. Channels like #product, #whats-happening-at-gitlab, and #is-this-known can be good places to publicize these messages.
  • Use the Pajamas Design System. Make sure your changes align with the design system and leverage available components. If there’s a need to update an existing component or propose a new one, follow the component lifecycle. If you have questions, ask a member of the Foundations group.

How will we measure success?

The team will track the total number of MRs merged with the Beautifying our UI label.

Risks

  • We don’t know how much time will be required during the experiment for these pairings to be successful, so we can’t predict the impact to participants’ regular milestone work, OKRs, and so on.
  • The experiment will focus on fixing friction points identified during heuristic reviews, which means that we won’t conduct user research. There is a possibility that we will inadvertently introduce new friction points.

Hiring Product Designers
Product Designers, Product Design Managers, the Director of Product Design, and Product Managers participate in our hiring process by interviewing Product Designer candidates. We have created guidelines to help support a consistent end-to-end hiring process.
Product Design Manager Workflows
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. This page contains workflows specifix to Product Design Managers
UX Themes
Introduction and usage guidelines for UX Themes
Last modified March 28, 2024: Fix broken link to PDM workflow page (303bc69e)