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 | 2024-06-12 |
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.
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.
As the GitLab product expands to include offerings for the entire DevOps 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.
GitLab currently uses SCSS variables for colors, spacing, and typography to drive consistency within the GitLab UI stylesheets. These variables are manually synchronized with the Figma component library that the design team uses, which sometimes leads to them falling out of sync. This causes mismatched expectations between design and dev due to an unclear source of truth, impeding design handoff. Design tokens have emerged as a standard approach for managing design system configuration. We will adopt this approach within Pajamas and GitLab UI to make design handoff more efficient and to prepare the way for high-impact theming work like an improved dark mode, accessibility-focused themes, and customizable content density. We presented an update, Getting dark mode to GA will be exciting and scary, in a recent UX Showcase.
Remove dependency on Bootstrap
The GitLab UI component library was built on BootstrapVue to speed up initial development of our design system. As we look to introduce design tokens into Pajamas, we have found that the Bootstrap and BootstrapVue libraries do not provide the flexibility we need to move forward with our rollout. We will vendor these libraries into our gitlab-org/gitlab-ui project so that we can modify them to meet our needs.
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.
Provide styles for our type scale
A type scale is a carefully selected set of type size and spacing settings that provide a harmonious balance in a typographic system. A type scale helps with consistency and visual hierarchy. We have defined our type scale in Pajamas, yet have not implemented these in our component libraries yet. This prevents our designers and developers from being able to readily use our type scale definitions.
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.