The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Stage | Foundations |
Maturity | Viable |
Last reviewed | 2025-02-05 |
Thanks for visiting this direction page on the Design System category in GitLab. This page belongs to the Foundations Stage and is maintained by Jeff Tucker.
This direction page is a work in progress, and everyone can contribute:
The goal of the Design System category is to enhance efficiency and quality for product designers, engineers, and product managers by developing and maintaining an integral piece of UX, design, and frontend infrastructure.
As the GitLab product expands to include offerings for the entire DevSecOps lifecycle, it's critical to provide support for teams building a cohesive experience. To serve these needs, the Design System category defines guidelines, best practices, and provides resources that inform how teams design and build products.
There are two focus areas:
The design system is a collection of resources, components, and guidelines used to make a consistent user experience in GitLab. Contributors focus on the building blocks that makes GitLab more usable, accessible, beautiful, performant, and robust. View Pajamas at design.gitlab.com.
The value of a design system is only realized when it's being used consistently and accurately in the product that consumes it. By focusing on component migrations (adoption), implementation, and tooling, the design system moves the product closer to using a single source of truth and increases our ability to make coordinated improvements.
Our design system has matured. With a robust foundation and a dedicated stage group, we’re ready to expand beyond our traditional focus on efficiency and work towards a future where the design system is a leader in craft and enabler of product quality at GitLab. This means evolving both our systems and team to better facilitate quality contribution, fostering a shared language with engineering, and ensuring our foundational pieces fit together to support an elevated GitLab experience.
We will be focused on the following challenges in FY26:
Dark mode is a fan-favorite among software developers – the original issue for dark mode collected nearly 1,000 positive reactions from the community. We introduced an alpha version of dark mode as a result of that work. However, we have some long-standing issues with our alpha that have kept us from driving adoption of dark mode (e.g. by respecting UA preferences for dark mode). We will revisit our current dark mode implementation once we have implemented design tokens for Pajamas and GitLab UI. Our key goal from this work will be to both improve the end-user experience for dark mode and to reduce the overhead on other GitLab teams that introduce new features.
Unified source of truth for the design system
By consolidating all design assets, guidelines, and component documentation into a single, authoritative resource, we can eliminate discrepancies and reduce confusion among team members. This centralized approach will not only streamline workflows but also ensure that all stakeholders have access to the most up-to-date information, ultimately leading to a more cohesive and polished user experience.
Introduce more patterns and guidelines
Expanding our Pajamas design system guidelines is essential for enhancing consistency and efficiency across GitLab's user interface. More comprehensive guidelines will provide clearer direction on component usage, accessibility standards, and interaction patterns, streamlining the design and development process. This will not only ensure a more cohesive user experience but also facilitate better collaboration between teams and faster onboarding of new members.
Measure and publish component health
Quality of individual components in Pajamas Design System varies and we do not have a way to communicate that maturity to consumers. By regularly assessing factors such as usage, performance, accessibility, and consistency with design principles, we can identify areas for improvement and prioritize updates effectively. Transparently sharing these health metrics not only fosters trust among users of the design system but also encourages collaborative efforts to enhance and refine components, ultimately leading to a more efficient and user-friendly product development process.
Support frontend working groups
Several teams across GitLab are contributing to working groups that impact the GitLab frontend. While the Design System group does not specifically own these projects, we are actively supporting them:
Watch our latest kickoff video to see our plans for the current milestone.
SCAN:SEMGREP
phase of our pajamas component spreadsheet. This means we have accurate counts to determine when we are done. Our MVC of the Pajamas Adoption scanner is also now out of "MVC" as we will look at capacity to schedule improvements to the UI.See our roadmap in GitLab.
Internal product designers, technical writers, engineers, and product managers.
When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.
Cookie Policy
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, enabling you to securely log into the site, filling in forms, or using the customer checkout. GitLab processes any personal data collected through these cookies on the basis of our legitimate interest.
These cookies enable helpful but non-essential website functions that improve your website experience. By recognizing you when you return to our website, they may, for example, allow us to personalize our content for you or remember your preferences. If you do not allow these cookies then some or all of these services may not function properly. GitLab processes any personal data collected through these cookies on the basis of your consent
These cookies allow us and our third-party service providers to recognize and count the number of visitors on our websites and to see how visitors move around our websites when they are using it. This helps us improve our products and ensures that users can easily find what they need on our websites. These cookies usually generate aggregate statistics that are not associated with an individual. To the extent any personal data is collected through these cookies, GitLab processes that data on the basis of your consent.
These cookies enable different advertising related functions. They may allow us to record information about your visit to our websites, such as pages visited, links followed, and videos viewed so we can make our websites and the advertising displayed on it more relevant to your interests. They may be set through our website by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant advertisements on other websites. GitLab processes any personal data collected through these cookies on the basis of your consent.