Source Code Rules
GitLab - Staff Product Designer
Imagine trying to lock down your code, only to find the controls you need hidden in different corners of the product. This is the issue that first surfaced with “protected branches” and “approval rules.” Instead of a single, intuitive workflow, security admins had to jump between pages, repeat steps, and piece together a mental map of what was actually protected.
One enterprise customer described it:
“These are both branch-dependent, but to manage them you have to go to two different parts of the UI… It’s duplication of effort, and not a great user experience.”
The lack of a unified view made it hard to understand what was truly locked down, reduced operational efficiency, and created a competitive disadvantage. Because security features are a key driver of Ultimate tier adoption, solving this issue was not just a UX improvement—it was a potential revenue growth lever.
- Controls scattered across product
- Problem first surfaced with protected branches vs. approval rules
- Reduced efficiency + competitive disadvantage
- Direct revenue impact on Ultimate tier
Problem validation
Problem Approach
At GitLab, individual features are owned by different teams, but users experience them as part of a single workflow. As a staff designer, I needed to look across the product to solve the problem in broader terms—improving the overall security experience, not just a single feature gap.
The challenge extended beyond “protected branches vs. approval rules.” Safeguards like code owners, status checks, scan result security policies, push rules, and protected tags were scattered with overlapping purposes and inconsistent behavior, making them harder to configure, maintain, and understand.
To see the full picture, I built a feature comparison table analyzing all eight safeguards across purpose, configuration points, technical implementation, and user impact. This revealed that five features were variations of the same job, controlling branch access, and two addressed separate needs. The result was a clear, evidence-based definition of the true scope of the problem to guide solution design.
Key Takeaways
- Needed broad, cross-feature view
- Eight safeguards analyzed side-by-side
- Found 5 overlapping, 2 unique
- Clear scope definition for solution
Problem validation
Cross-Functional Coordination
Once we realized the problem crossed multiple product areas, it became clear we needed a single, unified solution. This required aligning seven stage groups—each with its own priorities and making collaborative decisions across teams.
To enable async participation without overwhelming stakeholders, I broke the work into focused discussion threads and issues, each dedicated to a specific decision or integration point. This allowed teams to contribute their expertise without getting lost in unrelated conversations, ensuring we reached alignment efficiently.
Key Takeaways
- 7 stage groups impacted
- One unified solution required
- Organized async decision-making threads
- Prevented discussion overload
Problem validation
User Research
Because the problem touched multiple areas, we needed confidence the solution worked across all of them. We conducted research to validate the challenge existed beyond just protected branches and approval rules.
Using cognitive mapping, we asked participants to visually arrange security concepts to see whether they thought in branch-first or rule-type terms. The results were clear: admins conceptualize protections by branch first (“lock down main branch”), not by rule type. This confirmed the foundation for our unified framework.
Key Takeaways
- Needed validation across product areas
- Chose cognitive mapping for mental model insights
- Users think branch-first, not rule-type
- Confirmed branch-first organization principle
Solution Design
Translating Research to Design
Research validated the core concept: organize by branches first, apply rules second. This branch-first approach aligned with users' mental models and reduced cognitive load.
I explored multiple UI patterns, from nested rule displays to dynamic grouping and card-based layouts, considering scalability for hundreds of branches.
Within engineering constraints, the optimal Minimum Viable Change was a Branch Rules section that unified protected branches and approval rules under branch-based organization. This eliminated duplicate branch selections, contextualized rules, and maintained familiar UI elements to minimize relearning.
Solution Design
Outcomes
After the MVC, I created a roadmap to expand the framework, prioritizing features by user value and complexity. Planned steps included adding status checks, moving code owners to a UI while keeping file options, and assessing push rules. I also noted efficiency boosts likeinline editing, rule duplication, and templates—while setting principles to keep branch-first organization, ensure backward compatibility, and support future rule types.
Key Takeaways
- Post-MVC roadmap for more features
- Prioritized by value + complexity
- Efficiency enhancements planned
- Principles set for future scalability
Solution Design
Impacts
- Set in place the direction Source Code group would follow for years to come
- Supported Ultimate tier growth - Improved workflows for high-value security features boosted adoption.
- Reduced cognitive load - All protections configured in one place, cutting context switching and errors.
- Set collaboration standard - Thread-based decision-making became a model for multi-team work.
- Advanced design systems thinking - Demonstrated value of cross-feature consolidation.
- Enabled future evolution - Extensible architecture prevented UX debt.
- Lowered maintenance overhead - Shared patterns reduced engineering costs.