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 Design Managers
UX works on issues in the following order:
Accepting merge requestslabel
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.
Every Product Designer in GitLab is empowered to triage issues with "~UX", "~UX debt", and "~UI polish" labels, or should be included for feedback by the responsible PM and EM instead. Use Priority labels to propose the time when the issue should be solved and Severity labels to communicate its impact on users. Always work to align and communicate with your PM and EMs on the labels assigned.
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.
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.
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.
For iteration inspiration watch our Product Designers discuss iteration at GitLab.
@mentionyour Product Design Manager on the issue for feedback. Product Design 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:
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.