Product Designers are responsible for work assignments in their stage group and at the UX department level. These include supporting community contributions to their stage group, contributing to the Pajamas Design System, reviewing other designers work, and more (see Priorities). 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
Product Design Managers
Designers are managers of one and responsible for managing their own capacity. Below is a list of some types of work that designers can work on throughout a milestone. We've divided them into three categories (must do, should do, and nice to do) to help with appropriate prioritization. Use these as a guide and collaborate closely with your Product Design Manager. For example, if you and your manager agree with investing more time on Pajamas issues for a milestone or two, then you may need to reduce the number of current milestone issues you commit to during that timeframe. Your manager can help you create the space within your capacity to do so.
Must do:
#ux-coworking Slack channel, or elsewhere. See related sections Design Reviews and Investigate possible dependencies.Deliverable.workflow::problem validation, workflow::solution validation, or workflow::design.Should do:
Stretch.Pajamas, pajamas::define, pajamas::design, pajamas::build, or pajamas::integrate. See Pajamas component lifecycle and the Pajamas issue tracker.Nice to do:
Seeking community contributions or other low-hanging usability problems you can fix with an MR.UXSee also How we use labels.
The Incubation Engineering Department utilizes a Single Engineer Group (SEG) to work on "new market" efforts with a directive to move fast, ship, get feedback, and iterate. Occasionally, SEG efforts touch high-usage areas of our product (such as the Issue and MR views), and these engineers will request temporary design support (through the Product Design Manager) to drive the experience direction.
Product Designers and their managers should feel comfortable performing in-depth design critiques in issues and as part of MR reviews like they do for their Product Design peers. The goal is for UX to closely collaborate with Incubation Engineering to ensure a great experience for our users.
Design reviews/critiques
The SEG is responsible for the design ideation of their focus. Product Designers are not responsible for solving the customer problem or putting together design assets for the SEG.
However, if an SEG would like a Product Designer to review and provide feedback (at any phase–early ideations, wireframes, high fidelity mockups, and so on) they can reach out to the Product Design Manager of the stage group/area of the product it likely impacts. It can sometimes be a challenge to know what group but any Product Design Manager can help you get in touch with the right designer.
Ideally, SEGs will give advance notice of when a design review is needed. It is best to let the Product Design Manager know as early as possible for better planning and capacity management of their teams.
Reviewing SEG merge requests
All MRs with user-facing changes gets a review from a designer. For SEGs, we treat them similarly to community contributions, in that we want the designer closest to the area to work with the SEG as they will be deeply versed in our existing product.
In some cases, the SEG focuses on new areas of the product that doesn't have a direct impact on current stage group experiences. In these cases, we utilize the GitLab Roulette automation to help assign a Product Designer to an MR for review. The automation occurs when adding the UX label to the MR.
Issue weights are optional, but weighting issues can be useful for planning. They enable Product Designers to understand their capacity, evaluate impact of time off, facilitate trade-off conversations with Product Managers, and help the Product Design Manager identify teams that need more UX support.
When weighting issues, we aim for velocity over predictibility. This means that we don't need to be accurate at first, we just need to get better. This paragraph has a useful explanation of estimation at GitLab.
Additional Notes:
Milestone Capacity Template:
- Total weights completed last milestone: 10
- Average capacity (average of weights completed last 3 months): 10
- Estimated capacity for current milestone: 7 (use your average capacity and subtract planned time off)
- Total current weights: 10
| Weight | Design Tasks | User Research Tasks |
|---|---|---|
| 1 | Mostly small UI changes leading to small incremental UX improvements. No users’ workflow involved in these changes. Requirements are clear and there are no unanswered questions. For example: A copy experiment or changing a button styling. | Synthesizing previous research findings and generating recommendations based on them. |
| 2 | Simple UI or UX change where we understand all of the requirements but may need to find solutions to known questions/problems. These changes should blend in with an actual user workflow. For example: Simplify Sign in / Register process the in trial flow. | Running a first click test or other type of unmoderated research study |
| 3 | A well-understood change but the scope of work is bigger. Several pages are involved and/or we're starting to design/redesign small flows or connect existing flows between each other. Designers may conduct extensive background research (previous issues, support tickets, review past user research, review analytics, etc). Some unknown questions may arise during the work. For example: Update the CustomersDot checkout page to allow subscription and billing information input, Experiment with adding a contact sales option in app. | A moderated, narrowly scoped research study with specific questions to answer, such as a usability review of a single page |
| 5 | A complex change where input from group members is needed as early as possible. Spans across multiple pages, and we're working on medium-sized flows that potentially connect with another area of the product There are significant open questions that need to be answered. The product designer may need to do some research on their own or in collaboration with a researcher, but this isn't always the case. Possible research activities might be to find and/or validate a Job To Be Done, conduct user testing or card-sorting, or do a survey. For example: UX Scorecard, How can we improve the dismiss action in upgrade moments. | A research study evaluating the usability of an end-to-end flow or multiple related features, or a usability study with a minor exploratory component |
| 8 | Complicated changes introducing a new user flow that connects with other large flows and may require input from other designers, product managers, or engineers from the same or another stage group. This is the largest flow design/redesign that we would take on in a single milestone. This requires research where the designer may or may not be working with a researcher to plan and conduct exploratory interviews or user testing sessions. For example: Onboard new signs up through an onboarding issue board. | An exploratory study investigating broad-based behaviors related to a single stage, including one or more distinct user groups |
| 13 | Highly significant changes impacting multiple user flows, a large new feature, and/or a complete redesign. This issue could significantly impact product strategy and would require critical input from others (the wider GitLab community, e-group, customers), and there are many unknowns. This necessitates research where the designer could team up with a researcher and other designers to gather input data, plan and conduct exploratory interviews, lead user testing sessions… It's unlikely we would commit to complete this issue in a milestone, and the preference would be to further clarify requirements and/or break it into smaller issues planned in several milestones. For example: An improved free trial sign-up experience for GitLab.com SaaS users. | An exploratory study investigating broad-based behaviors across multiple stages and multiple types of users, potentially involving team members from the different stages. |
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 at 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 in which 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.
Consider adding a User Experience section to your team's planning issues (example 1, example 2), which can include issues related to active design items for that given milestone such as research projects, UX debt, UI polish, or Pajamas components. Learn more about planning and capacity for product designers.
Having design problems added to the planning issue help make design efforts discoverable for the rest of the team and encourages cross-functional collaboration during workflow::problem validation, workflow::design and workflow::solution validation.
Other key benefits of making User Experience an official part of group's milestone planning include:
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 there are also undiscovered problems out there that are definitely worth solving. Here are a few activities and resources to inspire you!
Access instructions for Dovetail, Zendesk and Chorus.ai
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.
The visual design of GitLab has come a long way from naive simplicity to sophisticated complexity, but there's a third level yet to be reached — sophisticated simplicity (Sophisticated Simplicity, Marcel Weiher). There are three tenets of sophisticated simplicity to keep in mind as you're designing:
An imbalance in any of these tenets can lead to a less than ideal experience.
An interface that achieves sophisticated simplicity will reduce friction to access basic functionality and content, provide quick access to powerful features, and help all users become more proficient at completing tasks.
Here's a sample set of questions you can ask yourself when designing:
There are two evergreen design efforts that align with sophisticated simplicity:
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 are encouraged to coordinate Design Reviews on a regular candence with their teams.
In practice, this is what it means for designers:
#ux-coworking Slack channel and any other channel where you'd like to get feedback (e.g. your Groups channel, etc.). Be sure to provide a link to the item requiring review as well as a link to the location where feedback should be left. Capturing feedback in issues will ensure you can refer back to it later, whereas Slack messages will eventually disappear.Examples
Deciding who to include in a design review, whether an informal share or a request for feedback around specific questions, can be daunting when you are new to GitLab or a team. Here are a few guides:
#ux_coworking Slack channel or mention @gitlab-com/gitlab-ux/designers in GitLab. For navigation changes, also follow this guidance from the Foundations team.Any additions or changes to UI text require review by the group's Technical Writer. You should discuss plans and ideas during the Product Design phase. UI text includes button or menu labels, error messages in the UI or in log files, user-assistance microcopy, notification emails, and any other text that may be surfaced in the UI. Changes to UI text often have a far-reaching effect on documentation steps.
documentation label. Documentation changes resulting from UI text changes follow the Documentation for a product change workflow.Sometimes the designer, PM, and technical writer agree to display additional in-product reference information in a drawer component. The reference information should align with the existing documentation for the feature.
If the content that should go in the drawer doesn’t exist yet:
UX Researchers work closely with Product Managers and Product Designers to ensure research projects are focused and provide answers to design questions.
For iteration inspiration watch our Product Designers discuss iteration at GitLab.
@mention your 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.| Scenario | Figma | Design Management |
|---|---|---|
| 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 breakdown label and stay involved by walking PM and Engineering through the proposed solution and participating in the conversation to break down the issue.workflow::scheduling label 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 development label.UX debt label to indicate that the product doesn’t meet UX requirements and will require immediate iteration.When reviewing an MR, click through to the issue to find the SSOT, which should be either a mock-up or Figma link in the Solutions section of the issue description.
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.
Our primary design tool is Figma. As a product designer or product design manager in the UX department, you will have a Professional Figma license and access to the GitLab team in Figma. You don’t need to do anything on your end, other than accept the invite sent to your GitLab email account during onboarding.
Anyone else in GitLab can access your files when you either share the file URL or invite them directly via email, but we ask that you only give them “can view” permissions. Anyone with “can edit” permissions is considered a paid seat and must have approval. A user with “can view“ permission will still be able to comment on and inspect design files.
GitLab has a public Figma profile where anyone can duplicate or remix files we have published. You can view our profile under the Community tab of the GitLab team section, or navigate to https://www.figma.com/@GitLab.
Do not create additional teams. An editor is billed for each team they are on, and we’ve only allocated resources for one team.
Figma has four levels of access, also called Permissions, for Professional teams. Permissions can be set at a team, project, and file level.
View complete permission details
Figma's cloud storage contains all design files under our Organization account and only the Pajamas UI Kit files are published to our GitLab Product Design community page and available publicly. It's recommended that you back up any non-confidential design files you'd like to have a record of for future reference or portfolio use by saving a .fig file and storing via your preferred method.