Challenge

Multiple teams across GitLab were building data visualization features independently, every dashboard, chart, and table reinvented the same primitives, with slightly different spacing, density, and interaction patterns. This inconsistency was eroding trust in the data itself and forced individual teams to reinvist the wheel everytime they wanted to tell a story with data. There was no single owner for how data should be shown across the product.

My role

  • Led the creation of GitLab’s dashboard-specific guidelines and the updates to the data-visualization component library
  • Established and ran dashboard-framework office hours to drive adoption across product groups
  • Collaborated with designers from every product area presenting data in their work
  • Partnered with frontend engineers to ensure Figma components matched GitLab-UI implementations, reducing design-to-development friction
  • Became code owner for the data-visualization section of GitLab’s design system

Approach

I conducted a pattern audit across product groups already building data-heavy features, identifying common needs, divergent solutions, and the gaps that were forcing each team to invent its own patterns. The audit helped to inform a concrete inventory of what existed, what was missing, and where the highest-leverage interventions were.

Examples of inconsistencies
Examples of inconsistencies

Defining the system, not just the screens

I established comprehensive guidelines for data presentation and dashboard interaction patterns, filtering, drill-downs, settings, exporting, sharing, composable for any data surface rather than prescribed to a single workflow.

Dashboard filtering guidelines
Dashboard filtering guidelines
Dashboard panel guidelines
Dashboard panel guidelines
Single stat component example
Single stat component example

Adoption as a design problem

I ran dashboard-framework office hours, embedded with teams adopting the new components, and treated questions from other designers as input to the system rather than support load. This process surfaced questions that should have had answers in the documentation already.

Solution

A horizontal data-visualization system that includes:

  • Guidelines for data presentation and dashboard interaction patterns (filtering, drill-downs, settings, exporting, sharing)
  • Standardized components available in both Figma and GitLab-UI
  • Documentation and best practices for designers and engineers across the organization
  • An adoption motion (office hours, embedded collaboration) that compounded the system’s reach

Outcomes

  • Code ownership of the data-visualization section of GitLab’s design system — a structural role rather than a one-off contribution
  • Cross-team adoption — multiple product groups could implement data features faster using shared components and patterns
  • Visual and behavioral consistency across data surfaces, increasing customer confidence in the data itself
  • Internal consolidation — GitLab teams began adopting standardized patterns, making their workflows more efficient
  • Horizontal leverage — the same foundations now serve multiple business verticals and personas

What’s next

This work is ongoing. The current initiative is modernizing GitLab’s data visualization color system — moving palette generation to OKLCH for perceptually uniform color across hues and themes, restructuring into a three-tier token architecture (primitive → semantic → component), expanding the categorical palette from 5 to 8 hues, and adding formal interactive-state definitions and toggleable pattern-fill support for accessibility. The goal is to bring Pajamas’s data-viz foundation up to the bar set by IBM Carbon, Atlassian, and GitHub Primer.

This foundation made it possible to take on a deeper structural problem in how GitLab exposes data to customers — see Rethinking GitLab’s Data Access Model.