- You are here:
- GitLab Direction
- Product Stage Vision - Create
- Group Direction - Ecosystem
- Category Direction - Frontend & UX Foundations
This direction is constantly evolving, and everyone can contribute:
- Please comment, thumbs-up (or down!), and contribute to the linked issues and
epics on this category page. Sharing your feedback directly on GitLab.com is
the best way to contribute to our vision.
- Please share feedback directly via email,
Twitter or on a video call. If you’re a GitLab
UI or Pajamas user and have direct knowledge of your needs, we’d especially
love to hear from you.
The Frontend & UX Foundations team is responsible for leading the direction of the experience design, visual style, and technical tooling of the GitLab product. This category encompasses two broad areas of focus:
- Tooling-focused enhancements
- User-focused enhancements
Tooling-focused enhancements include:
- Improving webpack and optimizing frontend assets.
- Improving the debugging experience, linters, and documentation with an emphasis on performance.
- Shepherding migrations away from deprecated technologies.
- Reducing technical debt.
- Addressing Progressive Web Application needs.
User-focused enhancements include:
- Building a cohesive and consistent user experience, visually and functionally.
- Providing comprehensive usage guidelines, reusable components, content standards, and usability documentation.
- Building in accessibility.
- Reducing user experience and design debt.
Both of these areas lead to a greater user and contributor experience while also increasing operational efficiencies. Our goal with the foundations team 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.
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.
Foundations 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.
What’s in progress, next, and later
- Creating, building, and styling foundation components. We identified 36 foundational components that are central to building and maintaining features at GitLab. In order to streamline the process of implementing components, we’ve defined four stages of a component lifecycle: Create, Build, Style, and Integrate. This first effort is aimed at completing the first three stages (create, build, and style) of the 36 foundational components. This will allow designers and engineers to have a robust system to draw from when designing and building GitLab products.
- Moving our Pajamas UI Kit from Sketch to Figma. The move to Figma allows for greater collaboration, as well as community contributions. Currently, Sketch is only available on Mac platforms and there is no real-time collaboration features. Figma will allow us to provide a UI Kit that is available across platforms, while being available for community contributors to utilize for free. It will also promote collaboration through its use of real-time editing capabilities and version history. We will also be able to streamline developer handoff by simply linking to the design file, reducing the need for additional plugins such as Sketch Measure.
- Updating our color palette to address color contrast for accessibility, and to normalize the palette across hues so that we can better systematize variable use throughout the UI.
- Creating a comprehensive action plan for integrating components into the GitLab product.
- Auditing and updating our existing VPAT.
- Building comprehensive accessibility standards into our workflows.
- Deprecating FontAwesome icons in favor of our own SVG library.
What we’re not doing
Building and integrating all components across GitLab. The scope of this category is to provide guidance and governance for our design system and related tooling, and is staffed with dedicated UX 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 FE/UX Foundations has some Frontend Engineering capacity, it can’t be responsible for creating and implementing everything.
Today, we consider our FE/UX Foundations to be Viable. Below is how we think we’ll grow that maturity level over time:
- Viable: A centralized system exists for product teams to contribute cohesive and consistent assets that aid in building the GitLab product. Documentation is in place to help offer guidance. Some reusable components exist and adhere to usage guidelines. Accessibility standards are followed in some cases. (Where we are today)
- Complete: A centralized system exists for product teams to contribute cohesive and consistent assets that aid in building the GitLab product. Documentation is in place to help offer guidance and these docs are consistently disseminated, enabling product teams to make autonomous decisions about component usage. Almost all reusable components exist, adhere to usage guidelines, and are referenced as the single source of truth. Some components are fully integrated into the GitLab product. Accessibility standards are followed in most cases.
- Lovable: A centralized system exists for product teams to contribute cohesive and consistent assets that aid in building the GitLab product. Documentation is in place to help offer guidance and these docs are consistently disseminated, enabling product teams to make autonomous decisions about component usage. Almost all reusable components exist, adhere to usage guidelines, and are referenced as the single source of truth. Almost all components are fully integrated into the GitLab product. Accessibility standards are followed in almost all cases.