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 Chris Micek maintains it.
This direction page is a work in progress, and everyone can contribute:
The Pajamas Design System (also known as Pajamas or simply the design system) is the foundation for how we design and build product experiences at GitLab. It’s a shared system of design tokens, components, patterns, and guidelines that enables teams across the company to create cohesive, accessible, and high-quality user experiences efficiently and at scale.
Efficiency means solving common design and implementation problems once and making those solutions easy to reuse. Quality means providing the assets, structure, and guidance teams need to create a unified and predictable experience across the entire product.
The Design System group maintains and evolves the design system in close partnership with contributors. We define best practices, improve the quality of components and patterns, and triage issues that span the product. Our goal is to help teams build better experiences faster by defining and strengthening the shared foundation that brings together the work of many teams into a unified product.
The design system provides a strong foundation for design and implementation across GitLab. However, historically focusing on components has led to an under-emphasis of patterns, templates, and complex interactions. While teams are generally able to assemble components into more complex workflows and experiences, they often do so in different ways. Without shared guidance or abstractions at this level, the result is duplication, inconsistency, and user experiences that diverge across the product.
We're focusing on filling long-standing gaps in the design system. These include areas where it lacks the structure or guidance to support complex workflows. This work may involve clarifying multi-step interactions, defining layout patterns, improving structural templates, or documenting the expected behavior of interconnected components. In parallel, we're auditing existing components to address long-overdue issues, such as missing documentation, accessibility gaps, or technical debt that limits adoption.
Contributing to the design system has become harder over time. The process can feel opaque, slow, or unwelcoming. At times the Design System group has acted more like a gatekeeper than a partner. This is a serious problem because it limits the ability for the system to grow and creates friction for teams doing good work.
We’re actively working to fix it. That means clarifying what belongs in the design system, simplifying how teams submit and review contributions, and improving how we collaborate with contributors across design and engineering. Collaboration should feel productive, not painful. Teams should feel confident bringing proposals forward knowing they’ll get constructive engagement.
We’re rethinking how the design system is structured and how we scope, categorized, and integrate contributions. Along with our processes, it must support different types of contributions, with clear expectations and appropriate levels of review.
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.
We’re revisiting the current state of components and patterns across the design system. This includes auditing what exists, identifying quality or usability issues, and working through pre-existing feature requests. As part of this, we use a component health assessment to evaluate where components fall short and where improvements will have the most impact.
We’re also focused on filling persistent gaps by incorporating components and patterns that have lived outside the design system for too long. Teams rely on these elements today but have lacked clear, centralized guidance or support. Beyond components, we’ll expand our focus to include patterns for layout composition and broader interface structure.
We’re introducing core and extended layers to the design system. The core layer contains building blocks that are broadly applicable and maintained by the Design System group. The extended layer has lighter governance, offers more flexibility, and teams contribute to and own it. This approach supports more contributions, reduce friction, and reflect the reality of how teams work at GitLab today.
We’re working to reduce friction and the cognitive load of using the design system. This includes making it easier to spin up a project using the design system, easier installation, and making it easier to use for quick prototypes or projects outside the core product. We’re also looking into providing more information about the design system code API for consumption where developers are working, like in AI and IDEs.
We launched dark mode as a fully supported feature across the GitLab product. This was a cross-functional effort that required deep collaboration between the Design System group and teams across GitLab. As part of this work, we transitioned the product to use design tokens for color, replacing hard-coded values with a more flexible system. This shift not only made dark mode possible, but also established a more scalable and maintainable foundation for future theming, visual refinements, and accessibility improvements.
Building and integrating all components across GitLab. The scope of this group is to provide guidance and governance for the design system and related tooling, and is staffed with dedicated product designers and engineers to support that. Creating and implementing components across the product requires participation from every group and category.
Internal product designers, technical writers, engineers, and product managers.