Summary

When I joined the Optimize team, the initial objective was narrow: enhance group and project-level analytics dashboards. But two problems surfaced immediately in research:

1. Dashboards and metrics existed only at the group or project level. There was no way to roll up data across groups, and users had to navigate to a specific group or project before they could even find the data they needed.
2. The dashboards themselves were static, with hardcoded metrics and date ranges that customers couldn’t change.

Digging into why revealed the deeper systemic issue: data access was coupled to GitLab’s application hierarchy, not to user permissions. The symptoms were dashboard complaints; the cause was the access model. This forced customers to work around the product entirely, extracting data through GitLab’s APIs into separate BI tools.

The work was reframed around two objectives:

1. Make data available at the organizational level, so customers can aggregate metrics across groups or focus on the projects that matter to them
2. Replace rigid static dashboards with a customizable framework, letting customers build views that match their actual analytical needs

Challenge

Decoupling data access from application hierarchy to unlock cross-team analytics

• Data access: GitLab’s data access was tied to its nested group and project structure rather than to user permissions. The consequence: customers couldn’t roll up metrics across teams they managed unless those teams shared a parent group; most cross-team analysis was simply unavailable. A model that should have empowered cross-team decisions was actively preventing them.
• Navigation: Because dashboards were scoped to groups and projects, users had to know where data lived before they could see it, first navigating to the right group or project. Analytics had no single home; it was scattered across the hierarchy.
• Static dashboards: Even when users found the right dashboard, the metrics and date ranges were hardcoded. Customers couldn’t tailor views to the questions they were actually asking, which is what drove them to export data into external BI tools.

My role

Lead product designer. My mandate was to rethink the data access model end-to-end so customers could analyze data along their real organizational shape. I worked closely with the Group PM and two engineering managers across the Optimize and Platform Insights groups (~15 engineers combined), with the Foundations team on navigation alignment, and with designers from every product area the change touched.

Approach

Naming the systemic constraint

I worked with Product and Engineering to map the existing system explicitly: data access was bound to application structure, and every downstream limitation followed from that single coupling. Until the coupling was named as the problem, every team was solving symptoms.

Exploring the options

I joined customer calls with my PM to hear how the coupling surfaced in real workflows, then worked through the range of access-model options: where access should live, how far to pull it away from the group tree, and what each choice would cost users and engineering. I evaluated the trade-offs with engineering before committing, so the model we landed on was chosen against real constraints rather than assumed ones.

Engineering partnership on what was possible

I partnered with engineering on what extensions GLQL (GitLab’s query language) would need to support cross-group queries and visualization rendering. Decoupling the access model was the design move; making GLQL support it was the engineering one, and the two had to be designed together.

One front door, built on shared foundations

With the Foundations team, I aligned this work with GitLab-wide navigation changes so every dashboard became reachable from a single entry point instead of being buried in the group tree. The dashboard surfaces themselves were built on patterns from a parallel initiative (see Data Visualization Design System), so the access-model rethink could be evaluated on its own merits without each team rebuilding dashboard UI from scratch.

Solution

• A single point of entry: updated navigation putting every dashboard in one predictable place
• A customizable dashboard framework: self-service creation, customization, and sharing for users with the right permissions
• Flexible aggregation across GitLab’s group structure, so customers could roll up metrics at the organizational level that actually mattered to them

Outcomes

The work had moved from vision to shipped foundation:

• The deprecation of the legacy static dashboards was approved, and both the Optimize and Platform Insights groups committed roadmap to the new model
• Early customers and internal teams could finally roll up metrics across the teams they managed, regardless of where those teams sat in the group hierarchy
• The customizable dashboard framework shipped, replacing engineering-mediated dashboard creation with self-service creation, customization, and sharing
• 5 internal teams consolidated their reporting onto the framework instead of building their own dashboards from scratch
• The framework became the foundation for new products like the Engineering Intelligence Dashboard, featured at GitLab’s Transcend event on Feb 10th, 2026

Full rollout is still in progress. These outcomes are from the first phases of adoption.

Key learnings

Most “we need a better dashboard” requests are access-model requests in disguise. The dashboard is the visible surface; the constraint lives upstream, in how data is exposed and aggregated. The access model, the part the user never sees but which determines what any dashboard can ever show them, was the highest-leverage design problem on the project.