Like other departments at GitLab, we follow the GitLab Workflow and the Engineering Workflow. Reviewing those resources is a good starting point for context on the Product Designer workflow below.
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.
Working on issues
Scheduling of issues in a milestone
All issues in a milestone labeled Deliverable that need UX will be assigned to a Product Designer by the kickoff. The Product Designer(s) for a given area should coordinate with the PM and their backup during scheduling for any work that is critical. Product Designers assign themselves to issues in a milestone and should aim to schedule 80% of their capacity to work on responsibilities as outlined in the role descriptions, blocking off the remaining 20% for other proactive work. This can be anything from exploring GitLab as a product to exploring competitive products and how GitLab compares to them to conducting their own research and interacting with users and other team members.
Issues labeled Stretch may or may not be assigned to a Product Designer by the kickoff.
Priority for UX issues
UX works on issues in the following order:
Has the current release milestone and is labeled Deliverable
Has the current release milestone and is labeled Stretch
Product Managers(PM) and Product Designers are very closely related, although they might seem different. Both PMs and Product Designers work within the problem–solution spectrum in order to better understand the problem that needs to be solved and to determine the most viable solution that addresses that problem. Over communicate with PMs—it's the best way to understand the problem and arrive at a solution.
Bring another designer in to have an additional set of eyes on your process if needed. This might make it easier to discuss holistic design decisions and to provide feedback regarding any uncertain elements in your work. Shoot for getting feedback on at least two of your important deliverables.
Loop in other members of engineering. Encourage them to contribute to finding the solution. They will have important insight into possible technical limitations.
Before coming up with any solution, discuss the scope with the PM, ask questions, and define what the problem really is (often it's not what people think it is).
Define the personas related to the problem space by populating the target audience section in the issue or epic description and by labeling accordingly with the following labels. That way everyone is aware of who we are developing for and is able to discover related problems/features.
Investigate whether there is existing UX Research or data that could help inform your decision and measure the results. If there isn't, consider looping in UX Researchers to conduct or assist you in conducting research for the problem.
UX issues have a tendency to expand in scope. Aggressively split off new issues, ideas, and concepts into their own issues. Mark the new issues as related to the original issue. Large issues become really challenging to drive decisions in and make progress on. If you’re ever unsure how to split apart large issues, work with the UX Manager.
Developers should be able to ship a product within one lifecycle. If a feature is too large to ship within one release, work together to determine the best way of splitting the feature into smaller segments.
Bring developers into the conversation early. Ask for feedback on how to split up features while still maintaining the integrity of the UX.
Encourage developers to scope down features into multiple merge requests for an easier, more efficient review process. When deciding whether to merge into master or a feature branch, be mindful of maintaining the integrity of the UX.
When breaking up features into smaller parts, make sure that the end design goal is known. Giving everyone the full picture will help developers write code aimed at achieving that goal in the future.
Keep the issue description updated with the agreed scope, even if doesn’t impact your work. This is everyone’s responsibility. The issue description must be the Single Source Of Truth (SSOT), not the discussion or individual comments.
Propose a solution:
Add comments with your proposals. Propose one solution, not multiple alternative solutions for others to pick, as this undermines your position as a UX expert and leads to a design by committee situation. If you have a good reason to propose multiple alternative solutions make sure to explain why.
@mention your UX Manager on the issue for awareness and feedback.
Wireframing, mockups, and prototyping all have their own place. You should utilize the best tool for communicating a problem/design/solution.
Proposals don't need to have images. Sometimes words can paint a surprisingly good picture of how an experience should feel, look, and behave.
Frame discussion around the problem being solved, not the designs specifically.
Anticipate questions that others might have and try to answer them in your proposal comments. You don’t have to explain everything, but try to communicate a bit of your rationale every time you propose something. This is particularly important when proposing changes or challenging the status quo. This reduces the feedback loop and time spent on unnecessary discussions while contributing to the credibility of the UX Department, who deal with a lot of seemingly subjective issues.
Keep the SSOT updated with what’s already agreed upon so that everyone can know where to look. This includes images or links to your design work.
If you are proposing a solution that will introduce a new UX paradigm, or change an existing one, please consider the following:
Will this pattern be inconsistent with other areas of the application?
Will other areas of the application need to be updated to match?
Does this new pattern significantly improve the user experience?
If you decide that it is worth changing/updating the pattern, there are additional steps that must be followed. See the Maintain section below for those steps.
Once your work is complete, make sure that the issue description, the SSOT, is updated with a section called "Solution". This is where you should direct people when they have questions about what should be done and how.
Not all issues are scheduled immediately which means changes are likely needed when the issue is prioritized. The UX designer responsible for a particular stage group should be aware of open issues within their product area and work to prioritize them accordingly with their respective product managers, even if they are not the original designer who worked on the issue.
To stay up to date with issues in your product area, subscribe to the label that matches your stage group.
Review issues within your stage group label regularly.
Actively contribute to planning meetings to ensure all open issues are being discussed and prioritized.
When working on an issue, keep the SSOT in the description updated until the issue is closed. This applies to both text and mockups. Previous content (by a PM, for example) should be removed or archived into a separate section in the description. If the developer working on the issue ever has any questions on what they should implement, they can ask the designer to update the issue description with the design.
When the issue is actively being worked on, make sure you are assigned and subscribed to the issue. Continue to follow both the issue and related merge request(s), addressing any additional UX issues that come up.
UX is part of the MR review process.
UX Review requests should be prioritized, tackle them as quickly as you are able.
Test it locally, do not rely on screenshots.
Be thorough, there should be as little back and forth as possible.
If you are asked to review an MR for an issue you were not assigned to, remind the author who the assigned designer is and assign to original designer for review.
When reviewing an MR, please use the following order of importance:
Functionality first - does it work?
Edge cases - are there any unexpected edge cases?
Remember to stick to the issue, create issues for further updates to avoid scope creep.
If the UX work introduces or changes any of the UX standards or building blocks:
As applicable, create issue(s) to update areas of the application that are affected by this pattern.
Add an agenda item to the next UX weekly call to inform everyone of those changes.
If the change/addition is a significant one, consider adding it to the Company Call to inform the company of the changes.
As design can be subjective, discussion can heat up. Always try to be direct but kind. Try to give your best reasoning for your choices, and evaluate everyone's opinions. Come up with a solution instead of discussing endlessly. If you think additional perspective is needed, mention a fellow Product Designer in the issue.