The UX Department works alongside the community, Product Managers (PMs), Frontend engineers (FE), Backend engineers (BE), and the Brand team. PMs are responsible for kicking off initiatives and setting the product direction. PMs define the "what" and "why" for feature-related issues by gathering customer and user feedback, and they give GitLab team members and the wider community space to suggest and create.
UX should assist in driving the product vision early in the process. We inform the vision by conducting foundational research and facilitating discussions with community members, customers, PM, FE, and BE. We are elevated above just the transactional workflow and generative in creating work, rather than just executing tasks. We align with the Brand team's direction for GitLab and incorporate brand standards and "brand moments" into the product when appropriate.
Our mission is to collaborate with the wider GitLab community and fellow GitLab team members to rapidly create products and experiences that customers value over competitor products and toolchains. To achieve our mission, we commit ourselves to being:
The UX department is not solely responsible for the user experience of GitLab. Everyone is encouraged to contribute their thoughts on how we can make GitLab better by opening an issue. You can use just words or include images. These images can take a variety of forms; here are just a few examples:
If you are creating high-fidelity designs, please make sure to let others know that this is a proposal and needs UX review. You can ping anyone on the UX team for assistance. Use the design and UI changes checklist to help you think through how your design will read, look, and behave.
Anyone discussing or sharing information about competitors in public must follow our Public Discussion of Competitor Products Guidelines.
We'll always have responsibility for reactive tasks that help "keep the lights on," such as bug fixes and minor UX enhancements. But we also must carve out some portion of our time for proactive work that identifies existing pain points, redefines how we approach problems, and uncovers actionable innovation and improvement opportunities. This proactive UX work enables us to create the most complete, competitive, and resilient solutions.
It isn’t always easy to find the space for proactive UX work, but the challenge is worth it, because it's how we create a best-in-class product experience. And it's not just the UX team's responsibility; it requires a coordinated effort from Leadership, Product, and Engineering, too.
We're currently working to find the right balance between proactive and reactive UX work. While we don't have a prescriptive ratio, we also don't allot 100% of our available work time to reactive efforts. Before and at the start of each milestone, UXers should work with their managers to define the appropriate ratio, based on our active OKRs and stage group requirements. When there are questions about priority or scope, or when a UXer is concerned about meeting a deadline, they should immediately reach out to their manager to help them resolve any concerns. Comunicate early and often!
One example of proactive UX work is our UX Scorecards initiative. Another example is the foundational research that our UX Researchers lead (while inviting cross-functional partners to participate). Yet another example is the ongoing effort to beautify our UI, both through small, tactical changes and through our Pajamas Design System.
Designers use UX Scorecards to benchmark common user tasks. In many cases, tasks involve multiple stages of the product, giving designers visibility into how users traverse across stages. Designers follow with Experience Recommendations for how to improve the experience in upcoming milestones.
Here at GitLab, iteration means making the smallest thing that adds value and getting it out as quickly as possible. Working like this allows us to reduce cycle time and get feedback from users faster, so we can continue to improve quickly and efficiently.
Iteration isn't just one of GitLab’s six founding values, C.R.E.D.I.T, it is one of the foundational concepts in design thinking and user experience. Planning too far ahead without real-world feedback can cause you to build something that doesn't meet user needs.
Iteration is especially vital in an open-source community. Keeping changes small and iterative makes it easy for anyone to contribute. Here are some examples of how we are embracing the power of iteration and using it to build GitLab:
Pair Designing gives Product Designers a consistent partner to ideate with at the beginning of an effort and get feedback from during the design process, and conduct design reviews. It also gives Product Designers exposure to product areas outside of their own.
See the Design Pair Rotation list.
Every Product Designer is aligned with a PM and is responsible for the same features their PM oversees. Technical Writers each support multiple stage groups. UX Researchers support multiple PMs within a section.
UXers work alongside PMs and engineering at each phase of the process: planning, discovery, implementation, and further iteration. The area a Product Designer or Technical Writer is responsible for is part of their title; for example, "Product Designer, Plan."
In the spirit of having "stable counterparts," we plan headcount as follows:
Taking time off is important. It is equally important to come back to work and feel refreshed. We discourage team members from checking work-related activities while on leave as a way of feeling less overwhelmed when returning. To prevent this, your stage design peers, or manager if you do not have stage design peers, will serve as your backup when you are on PTO (paid time off) by:
Backups are responsible for addressing critical UX work while a designer is away. Critical UX work is defined as any work that addresses an outage, a broken feature with no workaround, or the current workaround is unacceptable. If a backup begins to feel overwhelmed with workload, they should immediately reach out to their manager for help. Your manager will be able to help further delegate tasks when necessary.
When taking time off, be sure to communicate it with other people.
When returning to work, you are not responsible for responding to every To Do that accrued while you were away. Utilizing a tool such as PTO Tanuki helps reduce outdated mentions upon returning.
No matter how much time off you are taking: Always use PTO by Roots to set a role for your backup person during your PTO, and add the UX Calendar (internal only) to your settings (its calendar ID is in the Google Calendar settings), so your PTO events are visible to everyone in the department.
If you are taking at least 1 week off: In the GitLab Design project, open a new issue using the UX Coverage template and list the priorities and issues that the responsible backups need to cover while you are on PTO.
This section applies to Product Design and UX Research. For Technical Writing, read Technical Writer PTO.
When taking an extended time off, such as Parental Leave: Work with your manager to communicate with the relevant stable counterparts to ensure that UX workload for that stage is reduced in order to avoid burnout among other designers on the team. We do not expect designers to increase their capacity during your time off.
When responsibility for an individual stage, group, or category changes, we use the UX Transition issue template to provide a stable and consistent handoff among UX department team members.
The UX Calendar (internal only) is the SSOT for our team meetings. You can find the details for the UX Department weekly calls, Group Conversations, UX Showcase, and other team meetings here. These meetings are open to everyone in GitLab. Anyone in the UX department can add events to the Google Calendar. Managers and above can make changes and manage sharing, while ICs can make changes to events. Please reach out in the
#ux_managers Slack channel with any questions or requests.
We believe that strong cross-functional collaboration between Product, UX, Development, and Quality leads to the most successful products.
These roles should be well balanced, so that each group can contribute to the product and make informed decisions about what to build and how to build it. Collaboration enables us to build features that are desirable, usable, and feasible. It also helps GitLab to achieve business goals, delight users, and build software that's high quality, fast, and secure.
There are three essential parts to great collaboration: shared processes, appropriate tools, and psychological safety.
We follow GitLab's shared process referred to as the Product Development Flow.
UX research and design are essential componenents throughout the Product Development Flow. Talking to customers or potential customers to understand their problems is at the core of this idea.
We have a lot of collaboration tools available to us at GitLab. It's our responsibility to select the best communication medium for the situation and to understand when and how to use our tools. Zapier, another all remote company, wrote an article about collaboration tools and methods that help foster communication among remote teams.
|- GitLab: Issues and MRs
- Figma: Wireframes and Prototypes
- Google: Email
|- Zoom: Recorded meetings and screenshares
- Google Drive: Collaborative Documents
- Slack: Group Chat
|- Zoom: Live meetings (1:1s and coffee chats)
- GitLab Contribute: In-person
People thrive in environments where they can bring their unique perspectives to work, put ideas forward without fear, and openly debate and critique ideas in a healthy and productive way. Read more about Trust on Teams and why it matters.
The remote and asynchronous way we work can make it hard to know when collaboration is needed. Here are some things to think about:
UX readylabel when the work is ready for the Build track. Just before UX Ready is a great time for PM, UX, and Engineering to sync up a final time to make sure the issue is indeed ready for development. Learn more about how we use Workflow labels in the GitLab Docs.
The beginning of an epic is a good time to talk through the big picture with the product manager and rest of the team as often as possible. Visuals like journey maps and screen or user flows can help keep everyone on the same page and make these discussions richer.
There are several methods for you to preview, test, review merge requests (MRs), and contribute changes to the app, user documentation, Pajamas, or company handbook. We encourage MR authors to add screenshots or videos of their changes. However as they don’t cover all review aspects (for example, hover states, small viewports, accessibility, and so on.), you cannot rely on them exclusively and should always review the MR in a live environment.
The most common methods to review the MR in a live environment are:
|Gitpod (cloud)||GDK (local)||Review App||Sync with author|
|First start*||🏃♀️ Fast (<5 min)||🐢 Very slow (30+ min)||GitLab (>30 min)
Docs (>20 min)
Pajamas (~10 min)
Handbook (~10 min)
|🏃♀️ Fast (few mins)|
|Restarts||🏃♀️ Fast (<2 min)||🤷 Depends†||🚀 Very fast (secs)||🏃♀️ Fast (few mins)|
|Toggle feature flags||✅||✅||✅||✅|
*: The time needed to preview changes for the first time. Depending on the
method it includes steps like installation, build, deployment, etc.
†: When using a local GDK, the time it takes to restart it depends heavily on your local machine specifications.
§: Ability to save the current environment state, including its data, license information, feature flags (if applicable), etc.
¶: Only applicable for GitLab instances. Test data includes pre-created users, projects, branches, issues, merge requests, epics, etc.
We encourage you to read the most up-to-date documentation links below, but if you're more of a visual person, fear not! Check out the GDK and Gitpod walkthroughs YouTube playlist for walkthroughs and how-to videos of GDK and Gitpod. Note that some videos may be outdated.
Please contribute videos to that playlist with your tips or process when using your local GDK or Gitpod to review MRs or contribute changes.
To use Gitpod you must create a Gitpod account (free) and connect it to your GitLab account. If you launch Gitpod from any project on GitLab.com your accounts are automatically connected (see links below). If for some reason that doesn't work, see how to manually connect your GitLab.com account.
You can enable a feature flag by sending an API request to the review app in your local environment, or using a browser API request tool such as Reqbin.
To enable a feature flag using Reqbin, follow these steps:
If you get stuck using any of these methods, follow the tips below in order. Don't struggle on your own and, when in doubt, ping a UX member to facilitate finding the right help.
In FY23-Q2, we are piloting a Root Cause Analysis on 5 design projects to help drive insights about our design processes. Product Designers have the clearest view about "how we work" when it comes to design quality, so our goal is to understand their perspective on what's working well and where the team may need additional unblocking or support.
To ensure that we capture information from across the entire Product Design sub-department, each Product Design Manager will select one project from within their area of coverage to conduct an RCA. We will follow the blameless RCA guidelines outlined in the Engineering handbook with minor modifications to the template to fit our needs. Because this is a pilot, we will evaluate the effectiveness of the effort at the end of Q2 to determine: (1) whether it was useful and worth continuing and (2) whether the process needs additional modifications.