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:
workflow::solution validation, or
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.
Iterative design at GitLab combines the two industry-standard definitions of "incremental design" and "design iteration." Put simply, iterative design is the process of breaking down design solutions into the smallest change possible that improves the user's outcome. It's getting things quickly into the product to get feedback early and guide refinement.
When applying iterative design, you should consider the longer-term strategy or vision and work with your Product Manager to plan successive releases until it's realized.
Think big, ship small, move fast with iteration
"Our relationship with uncertainty: When we conduct research and design we have some level of certainty about how effective it’s going to be, but it isn’t until we ship it and get it in the hands of many users that we truly understand how effective the thing is that we designed."
A new designer's take on iteration
"Breaking things down creates psychological safety for me as a designer."
Sharing work and gathering feedback can happen at any time within the design process. We do this most frequently by sharing mocks and having open discussions in issues.
Design Reviews are a dedicated space for Product Designers to give and receive specific and sometimes in-depth feedback on ideas and possible solutions. Other benefits include:
We default to asynchronous design reviews so everyone can participate. Asynchronous Design Reviews are very similiar to their synchronous equivalent: designers share their work and provide context so their peers can offer valuable and constructive feedback. Product Design Managers coordinate Design Reviews on a regular candence with their teams.
Several teams start Design Reviews at the beginning of a milestone by creating a specific issue for designers to share a brief walkthrough video of their work — see an example issue and epic for the Create stage designers. In practice, this is what it means for designers:
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.
|Co-designing within a shared file||√|
|Providing, or seeking feedback while a design is still in progress, and not ready for MVC||√|
|Seeking feedback on a design with a larger audience||√|
|When feedback directly impacts an issue||√|
|Presenting design options or variations so the team can choose a direction||√|
|Sharing a prototype||√|
|Adding a to-do for a designer as it relates to in-progress design||√|
|Adding a to-do for a designer as it relates to an issue||√|
|Identifying visual regressions||√|
|Detailed redlines or specs||√|
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.