Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Product Designer Workflow

GitLab wide workflows

Like other departments at GitLab, we follow the GitLab Workflow, the Engineering Workflow, and the Product Development Workflow. Reviewing those resources is a good starting point for context on the Product Designer workflows below.

UX Department workflows

Product Designer onboarding

If you are just starting out here at GitLab, welcome! Make sure to review all the pages here in the UX section of the handbook, they will help you get oriented. There is also a specific page dedicated to Product Designer onboarding.

Planning and managing capacity

Product designers are responsible for stage- and UX-team-assigned work. Product designers are responsible for working with their stage peers and managers, as needed, to manage their capacity and complete their work on target and on time. Here are some guidelines to help Product Designers manage their work:

Product Designers:


Going out of office (OOO)

When going out of office (OOO), be sure to commit your working Sketch files to your progress folder in the GitLab Design repository, so designers covering for you are able to access working drafts of designs that may get shipped during milestones you are OOO.

Read more in the Paid time off and How we work pages.

Working on issues

This section provides an overview of how we work with issues. But it's very important for you to communicate with your PM and EMs early and often about how you should work together. Many teams have different flavors of this process as they have adapted to the needs of that product and that team.

Scheduling issues in a milestone

All issues in a milestone labeled Deliverable that need UX will be assigned to a Product Designer by the kickoff. Issues labeled Stretch may or may not be assigned to a Product Designer by the kickoff. Learn more about how we use Workflow labels in the GitLab Docs.

Priority for UX issues

UX works on issues in the following order:

Product design process

Define the opportunity:

Before you design:

Ideate and iterate:

Design reviews:

Gathering feedback is an essential part of the design process. Design reviews, similar to engineering code reviews, allow Product Designers to solicit feedback on proposed solutions. Because GitLab is an all-remote company, design reviews are also important for building shared understanding with the broader UX team.

Refine MVC:

Present an MVC solution:


Follow through

UX visual reviews

Sometimes you will find a UX problem but a decision will be made to merge the code anyway. When this happens, create a new issue to fix the problem and label it with UX Debt per this section on UX labels.

Follow-up after design is complete

For changes that affect Pajamas, such as introducing a new UI component, refining an existing component, or adding significant clarity to the usage of a component, you should take the following additional steps:

Working on UI text with technical writers

Any additions or changes to UI text require review by the group's technical writer, though you may have already discussed plans and ideas during the Product Design phase. This includes button or menu labels, error messages, user-assistance microcopy, and any other text that may be surfaced in the UI.

UX Showcase

The UX Showcase is a recurring meeting that allows each stage group to walk through various research findings and design solutions with key stakeholders from Product, UX, Engineering, and Leadership. These sessions are recorded and available on GitLab Unfiltered.

Showcase objectives:



Presenter(s) should come prepared with sufficient artifacts to tell the story of the user's journey. Use your best judgement to determine what will most effectively convey your story: a presentation, process diagram, journey map, series of mockups, prototype, etc.



Showcases will happen on a biweekly (every other week) basis. Meetings will be an hour long, allowing 4 stage groups to present. Each stage group Product Designer is expected to fill out the agenda (attached to the meeting invite) for that week prior to presenting. The current schedule can be found here.

Approach to communication

As design can be subjective, discussion can heat up. Sometimes team members won't agree on the best approach. Always try to be direct but kind. Try to give your best reasoning for your choices, and evaluate everyone's ideas and suggestions. Come up with a solution instead of discussing endlessly. If you think additional perspective is needed, mention a fellow Product Designer in the issue, or take it a step further and suggest that we perform some solution validation to let the data guide our design direction. Finally, remember that at GitLab we can disagree, commit, and disagree.

Creating a design evaluation (guidance for Product Designers)

  1. Create a new issue using the Design evaluation template in the UX research project and @ mention the relevant UX Researcher, UX Manager, and Product Manager for the product stage.

  2. Update the Design evaluation with the following:
    • Add as much information as you can to the issue.
    • Label the issue with the area of GitLab you’re testing (for example, navigation), the status of the issue (in progress), and the Product stage (for example, devops::manage).
    • Mark the issue as confidential until the research is completed so it doesn’t influence user behavior.
    • Assign the issue to yourself.
  3. The UX Researcher will quickly review the issue and advise whether it is feasible to send the study during the time frame you have requested (Occasionally, we may need to stagger when the study is sent since we do not want to bombard users with research studies). The UX Researcher will add a milestone to the issue.

  4. Create your test in UsabilityHub. Product Designers share a login for UsabilityHub. The credentials are stored in 1Password. Some tips for creating a test:
    • Use a descriptive test name. Make sure it includes the issue number of the research proposal.
    • We don't incentivize users to participate in design evaluations. In order to encourage participation, keep the test length under 10 minutes (UsabilityHub will provide you with an estimated completion time as you build your test).
    • Try to avoid priming users. For example, when writing tasks for a first click or navigation test, where possible, avoid using terms that appear in the interface or which give the answer away.
    • Always question whether you are using the right research methodology. For example, if you are asking lots of straight-up questions, would it be best to ditch the design evaluation and write a survey instead? Check out the UsabilityHub guides for common use cases for each methodology.
    • Remember what users say and what they do can be very different. Just because users prefer a design, doesn't mean they can use it. Find out more about when you should use preference tests.
    • Read more about how to test visual design.
    • If you're ever in doubt when creating your test, reach out to a UX Researcher!
  5. When your test is ready, update the Design evaluation issue with any outstanding information and ping the relevant UX Researcher for a final review.

  6. Once you and the UX Researcher are happy with the test, the UX Researcher will distribute the test to subscribers of GitLab First Look.

  7. When you and the UX Researcher feel that sufficient data has been collected, the test can be closed in UsabilityHub.

  8. You are responsible for analyzing any tests you have created. You are always welcome to reach out to a UX Researcher for assistance.

  9. Document the study within a Google document. The report should include:
    • Research hypotheses
    • Research methodology
    • Findings
    • Next steps/recommendations.
  10. Update the Design evaluation issue with the following:
    • Link to the report.
    • Unmark the issue as confidential.
    • Update the status of the issue to done.
    • Close the issue. You should stay assigned to closed issues so it's obvious who completed the research.