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.
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.
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:
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.
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.
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.
UX works on issues in the following order:
Accepting merge requestslabel
Part of the role of product designers is to lead and facilitate idea generation within our teams. We are all very busy working with PMs to drive forward our product roadmaps and solve known UX problems, but remember that there are also undiscovered problems out there that are definitely worth solving. Here are a few activities and resources to inspire you!
It is our responsibility as Product Designers to research how our work can impact other parts of the product and the work that other Product Designers are doing.
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.
@mentionyour UX Manager on the issue for feedback. UX Managers have a broader view of work that's happening across the product, enabling them to provide feedback that is helpful for maintaining strategic alignment, a consistent level of quality, and functional consistency.
workflow::planning breakdownlabel and stay involved by walking PM and Engineering through the proposed solution and participating in the conversation to break down the issue.
workflow::schedulinglabel and mention the responsible product manager to schedule it. It is also the Product Designer's responsibility to communicate with the assigned engineer to ensure they understand the solution.
workflow::ready for developmentlabel.
UX debtlabel to indicate that the product doesn't meet UX requirements and will require immediate iteration.
UX is part of the MR review process. Any MR that makes a change that is user-facing should be looked at by a designer.
Product designers should feel empowered to adapt the process to fit their situation, as long as they feel confident that UI changes are getting sufficient attention to avoid inflicting UX bugs or UX pain for customers. Some common scenarios include:
UX Debtper this section on UX labels.
You can read more in our Code Review Guidelines.
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:
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.
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.
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.
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.
Design evaluationwith the following:
navigation), the status of the issue (
in progress), and the Product stage (for example,
confidentialuntil the research is completed so it doesn’t influence user behavior.
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.
When your test is ready, update the
Design evaluation issue with any outstanding information and ping the relevant UX Researcher for a final review.
Once you and the UX Researcher are happy with the test, the UX Researcher will distribute the test to subscribers of GitLab First Look.
When you and the UX Researcher feel that sufficient data has been collected, the test can be closed in UsabilityHub.
You are responsible for analyzing any tests you have created. You are always welcome to reach out to a UX Researcher for assistance.
Design evaluationissue with the following: