Feature Flags

We had a sense of the user pain points from existing issues, but we wanted to validate and prioritize those as well as discover any additional ones we might not be aware of. To accomplish this, I designed and executed comprehensive user research to validate the scope and priority of feature flag problems.

Research Findings That Shaped Design Decisions

Mental Model Discovery: Environment-Strategy Independence

• Finding: Users thought about strategies (how to roll out) and environments (where to roll out) as independent concepts
• User Quote: "I want to define my rollout strategy once, then apply it to different environments as needed"

Information Hierarchy Insights

• Finding: Strategy type and current status were most critical for scanning behavior
• Workflow Pattern: Users primarily worked in list view, only drilling down for complex configurations. Information like parameters and environment details can be less prominent.

Scale Management Challenges

• Finding: Teams managing 50+ flags experienced severe navigation and organization problems
• Search Behavior: Users relied heavily on filtering and search to find relevant flags

Competitive Analysis Insights

• Finding: Users expected to be able to manage rollouts by percentage
• Finding: Users expected user-level controls

Core Architectural Innovation: Environment-Strategy Decoupling
I fundamentally redesigned the feature flag architecture by flipping the relationship between environments and strategies. The previous system forced users to select environments first, then add strategies to each one. This was completely backwards from how users think about deployments and created confusing 1-to-1 relationships where users often created 5x more rules than necessary.

The breakthrough
Making strategies the primary object that could be applied to multiple environments simultaneously, aligning with users' mental model of "I want to roll out this way to these places."

Key improvements

• Matched user mental models - Strategy definition separate from environment application
• Eliminated redundant configuration - One strategy applied to multiple environments
• Enabled flexible reuse - Same rollout approach across staging, production, review environments
• Reduced cognitive load - Clear visual relationships between strategies and environments

To surface critical information in list views without overwhelming, I used progressive disclosure to drive list design to scale gracefully from simple to complex use cases based on the primary task: Scanning many flags to understand current state.

Design Features

• Multi-faceted Filtering: By strategy type, environment, status, ownership
• Search Functionality: Name, description, and parameter search across all flags
• Saved Filters: Common filter combinations for different user workflows
• Strategy Type Badge: Color-coded indicators for percentage, user-based, environment-specific
• Status Indicator: Clear enabled/disabled state with environment context
• Parameter Summary: Key strategy parameters (percentage, user count) in compact format
• Environment List: Affected environments with visual hierarchy by importance

Design Factors

• Critical information: Strategy type, current status, affected environments
• Secondary information: Parameters, ownership, last modified
• Action priorities: Quick enable/disable as primary action

Designed centralized user list management to eliminate the repetitive work of recreating the same user groups across multiple feature flags. Previously, support teams had to manually rebuild customer lists for each flag, leading to errors and wasted effort when the same beta users or customer segments needed access to multiple features.

Centralized list management

• Reusable user lists: Create once, apply to multiple feature flags without recreation
• Centralized editing: Update user list membership in one place, automatically applies across all flags
• Efficient scaling: Support teams manage hundreds of users without per-flag duplication

I replaced the cramped dropdown environment selector with a spacious modal that provided full context and eliminated user confusion about which environments were affected. The tree structure naturally grouped related environments - production, staging, and review apps - with collapsible folders for dynamic environments and wildcard support for bulk selection. This design solved the core usability problem by giving users a clear overview of all environments, intuitive checkbox selection without confusing "additive rules," and search functionality to handle teams managing 100+ review environments efficiently.

Interface improvements

• Full context view: All environments visible simultaneously instead of cramped dropdown
• Hierarchical organization: Natural grouping of production, staging, and review environments
• Bulk selection support: Wildcard and folder-level selection for efficiency
• Clear selection states: Explicit checkboxes eliminated additive rule confusion

This project demonstrated how complex feature development can both leverage and advance GitLab's design system (Pajamas). The feature flags redesign fully adhered to established design system principles - using consistent typography, spacing, color tokens, and interaction patterns throughout the interface. However, the project required new patterns for information-dense list views, hierarchical selection, and progressive disclosure that weren't yet covered by the system. Rather than creating one-off solutions, I designed reusable components that could serve broader platform needs, ensuring consistency while expanding the system's capabilities for future teams.

• Badge patterns became reusable across other GitLab list interfaces
• Filter patterns adopted by other teams for complex list management
• Percentage rollout interface influenced other progressive delivery features
• Approval workflow patterns contributed to broader GitLab review systems

• Deep User Problem Understanding: Systematic research revealed problems beyond surface usability issues
• Research findings directly influenced technical architecture decisions: User experience requirements shaped API design and database optimization
• Technical Constraint Integration: Working within technical limitations while pushing for user-centered solutions
• Design thinking methodology adopted by engineering teams for problem-solving
• Collaborative process became model for other complex feature development
• Methodology influenced other product teams' approach to user research integration
• Cross-Functional Collaboration: Engineering partnership throughout design process, not just handoff
• Internal case study shared across GitLab's design and engineering organizations
• Approach featured in GitLab's publication about feature development