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.
UX Scorecards
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 and ensure your PTO is synced with the UX calendar.
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 Time Off by Deel 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.
Syncing your PTO with Google Calendar is a simple way of ensuring team members know when you are going to be out of office. To sync Time Off by Deel with Google Calendar:
SettingsCalendar IDTime Off by Deel applicationCalendar syncAdditional calendars to include? click on Add calendarCalendar ID you copied from Google Calendar and hit SubmitYour PTO dates should now automatically sync with that calendar.
We recommend all Product Designers sync their PTO with the UX Calendar so that it is easy to find all designers who are OOO in one location.
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_leadership 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.
| Asynchronous | Flexi-synchronous | Synchronous |
|---|---|---|
| - 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 ready label 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.
Remember:
GitLab provides various functions and services for different users' needs; cross-stage design collaboration is essential for creating consistent, intuitive products tailored to our users' needs. Use cross-stage design tips and guidelines to help your cross-stage design collaboration to be more efficient and effective:
There are several methods for you to review, test, and contribute changes to the app, user documentation, Pajamas, GitLab UI 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) |
| Make changes | ✅ | ✅ | ❌ | ✅ |
| Preview/test | ✅ | ✅ | ✅ | ✅ |
| Save state§ | ✅ | ✅ | ✅ | N/A |
| Toggle feature flags | ✅ | ✅ | ✅ | ✅ |
| Test data¶ | ✅ | ✅ | ✅ | N/A |
*: 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.
GitLab is a complex platform that helps teams shorten cycle times, reduce costs, stregthen security, and increase developer productivity. In order to make the DevOps lifecycle more approachable for all users, it is essential that each member of the Product Design department has general knowledge of Git and DevOps flows by frequently using the various features across the product.
The Product Design department builds confidence in these areas by using the product in a live environment and contributing small fixes to the various projects that make up GitLab, including the app, user documentation, Pajamas, and GitLab UI. Designers are not expected to be full stack developers, but we do expect designers to grow their basic development skills to build empathy and understanding for the workflows our users experience on a daily basis.
Additionally, building these skills has the added benefit of empowering designers to directly make small, meaningful changes to the product. Migrating components or updating UI copy, for example, improves the consistency, visual design, and accessibility of the app.
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 using a tool such as curl or Postman.
To enable a feature flag using curl, follow these steps:
<your access token> below.<your review app URL> below.<your feature flag name> below. curl --data "value=true" --header "PRIVATE-TOKEN: <your access token>" "<your review app URL>/api/v4/features/<your feature flag name>"
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.
#gitpod-gdk Slack channel.#gdk Slack channel.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.
Our RCAs are located in the UX RCA project. When preparing for an RCA, an issue is created using the UX RCA template.