Compliance Suite

Overview

Compliance features are the reason enterprise customers buy GitLab Ultimate. They are the hook that justifies the price premium for regulated industries, security-conscious organizations, and any company that answers to an auditor. If those features are hard to find, hard to use, or hard to understand, the business case for upgrading falls apart.

I owned the compliance UX at GitLab from inception through launch across several years, designing the experiences that helped grow revenue by millions every quarter. The core challenge was not building features, it was making complexity invisible.

The problem

Enterprise compliance sits at an awkward intersection. The people who need to see compliance features exist are procurement officers and security leads making buying decisions. The people who interact with them daily are developers who want to merge code, not think about regulatory requirements.

Design that serves the first group at the expense of the second creates friction that kills adoption from the inside. An admin can enable every compliance control available and still lose the deal if the development team reports that GitLab slows them down.

The goal was to build compliance capabilities that satisfied auditors without making developers feel like they were working in a cage. Make the guardrails feel like the natural shape of the product rather than a layer bolted on top.

GitLab is a large, complex application. Compliance features add real architectural weight to that monolith. The best outcome was features that were powerful enough to check every enterprise box and quiet enough that most users barely noticed them.

The information architecture problem

When I joined the compliance group, the features were fragmented. Settings lived in different places depending on whether you were an admin, a group owner, or a project maintainer. There was no coherent model that told a user where to look for compliance controls or why they lived where they did.

The most concrete example was Status Checks. They had been placed inside Approval Rules because both features lived in the merge request workflow. The logic made sense locally but it was wrong at the conceptual level.

Approval Rules answer the question: who needs to sign off before this merges? They are about people and permissions. Status Checks answer a different question: what external systems need to pass before this merges? They are about automated gates, not human approvals. Treating them as the same kind of thing confused users who understood one and not the other, and it buried Status Checks inside a section that did not reflect their purpose.

Moving Status Checks to MR Settings, alongside other merge request controls, gave them a home that matched their function. The change was an information architecture decision but the impact was an adoption one. Features that live where users expect to find them get used. Features that require users to already know where to look do not.

Designing for two audiences at once

The compliance work required holding two very different users in mind simultaneously without collapsing them into one.

The admin configuring compliance controls needed confidence. They needed to see that the controls were comprehensive, auditable, and trustworthy. The UI had to communicate authority and completeness. An enterprise security lead signing off on a GitLab deployment needed to feel like they had not missed anything.

The developer working inside those controls needed the opposite experience. The less they thought about compliance overhead the better. Merge request workflows should feel fast and clear. Required approvals should be obvious without being obstructive. Status checks should communicate pass or fail without demanding explanation unless something went wrong.

These two experiences had to coexist in the same product. The compliance UI served the admin. The merge request UI served the developer. The design job was making sure neither experience undermined the other.

Results

Compliance features became a direct driver of GitLab Ultimate adoption. The work contributed to millions in quarterly revenue growth by making the enterprise value proposition tangible and accessible rather than technically present but practically difficult to use.

The longer-term impact was architectural. Establishing a coherent model for where compliance controls live and how they relate to each other gave subsequent teams a foundation to build on. Features added after my time on the compliance group had a clearer home than they would have had otherwise.