Summary

When I joined the Optimize team, my initial task was narrow: improve the group and project-level analytics dashboards. Lean quantitative and qualitative research, plus customer calls with my PM, showed the problem was bigger than the dashboards. The static, predefined views were scoped to the wrong data and hard-coded to metrics customers hadn’t chosen, so customers were working around us entirely: pulling data through GitLab’s APIs into separate BI tools they had to buy and maintain.

I reframed the task as an opportunity to define a new vision for how data should work in the product:

1. Make data available at the organization level, so customers can roll up metrics across groups or focus on the specific projects that matter to them
2. Deprecate the one-size-fits-all static dashboards and replace them with a customizable dashboard framework, so customers can build exactly the views their questions need

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.

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.