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 | Manage |
Maturity | Viable |
Last reviewed | 2023-08-11 |
Thanks for visiting this direction page on the Design System category in GitLab. This page belongs to the Foundations Group within the Manage Stage and is maintained by Christen Dybenko.
This direction is constantly evolving and everyone can contribute:
Our goal with the Design System category is to treat the underlying foundation of GitLab as a first-class internal product which supports product designers, engineers, and product managers to more efficiently perform their roles.
This encompasses two broad areas of focus:
Tooling-focused enhancements include:
User-focused enhancements include:
We do inherit some styles from Twitter Bootstrap, our design system is quite complex and not the same.
You can download the compiled source of Pajamas, but this only scratches the surface of very complex system and the css only applies to GitLab. Team members contribute to each component in the GitLab UI project and view components in Storybook. SVGs and icons are added in the GitLab SVG project. The documentation that displays at design.gitlab.com is created in the Pajamas project.
Foundations is the team responsible for Pajamas, sometimes we have to ship a fix to one or more repos to fix a bug that effects all other features.
Each component of our Design System is found in our documentation.
At GitLab, we are migrating components from old architecture to new so we can have a consistent design system and user experience.
Pajamas consists of two types of components:
Whenever possible, it is ideal to utilize Vue components. However, since much of our codebase is Ruby on Rails, ViewComponents have been implemented in order to utilize the reusable component without them needing to utilize Vue.
Once converted, we can easily roll out updates to all components from one consistent place.
We approach the health of Pajamas' components from both an overview and individual perspective. Right now, our health for each component is tracked in this spreadsheet.
When tracking overall health we look for:
When tracking component health we look for:
Design Systems are never done
Right now we are undergoing a large component conversion effort. At best this might take us 3 years to complete.
We have many other very large projects coming behind this. We are actively figuring out how to add outsourcing and community contributions to the first 3 in this list:
As the GitLab product expands to include offerings for the entire DevOps lifecycle, it is critical to provide support for building a cohesive product that has the ability to replace disparate DevOps toolchains.
To serve these needs, we will work with the Groups and Categories across GitLab to contribute to our design system, Pajamas, while also continuing to define guidelines and best practices that will inform how these teams are designing and building products. Additionally, this team will act as a centralized resource, helping to triage large scale technical and experience problems as the need arises.
Design System category is focused on supporting internal users and product teams, with a focus on four cross-functional counterparts: Product Designers, Technical Writers, Engineers, and Product Managers.
We also aim to improve the community contributor experience by streamlining the process of writing consistent code that conforms to set practices.
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.Building and integrating all components across GitLab. The scope of this group is to provide guidance and governance for our design system and related tooling, and is staffed with dedicated Product Designers to support that. However, creating those components and implementing them throughtout the application is a massive lift that requires participation from every Group and Category. While Foundations has some Frontend Engineering capacity, it can’t be responsible for creating and implementing everything.
Since this category is for internal users, it does not map directly to the Product definitons of maturity.
We consider our Design System to be Viable.
Below is our own definition for how we’ll grow that maturity level of this design system platform over time:
Foundations work covers a wide range of issues when it comes to our Design System. Historically we had a Working Group for GitLab UI, but the work on our Design System is a continuous effort.
We invite Frontend Engineers from other Teams and Community Contributors to pick up frontend-related issues if they have an interest in the UX/FE Foundation work.
Issues that are ready to be picked up are labeled with the
ux-foundations-needs-fe
label.
GitLab Team Members are able to self-identify as foundations_buddy
Domain Experts
if they are interested UX/FE Foundation work.
Doing so will help our Product Designers to reach out to folks in order to get Engineering support.