Show groups tab on Members page when there are no groups
Problem statement
The Groups tab on the Members page is currently hidden when no groups have been invited to the project/group. This implementation deviates from GitLab's design patterns and creates several user experience issues:
- Inconsistent UI patterns: Most tab interfaces throughout GitLab display tabs even when empty, showing appropriate empty states rather than hiding the tab entirely
- Poor feature discoverability: Users cannot discover the ability to invite groups to projects when the tab is completely absent
-
Missing educational opportunity: Without an empty state, we lose the chance to:
- Guide users on how to add groups to projects
- Explain when/why group additions might be restricted
- Clarify the benefits of adding groups vs individual members
This pattern inconsistency affects both the Project Members and Group Members pages, creating a confusing experience where tabs appear and disappear based on content rather than maintaining stable navigation.
Goals
- Align with GitLab design standards: Implement empty state patterns consistent with GitLab's Empty States guidelines
- Improve feature discoverability: Ensure users can discover and understand group membership capabilities regardless of current state
- Provide contextual guidance: Use empty states to educate users about group permissions and guide appropriate actions
- Maintain UI stability: Keep navigation tabs visible and predictable across different states
Implementation proposal
Display Groups tab with empty state
- Always display the Groups tab in both Project and Group Members pages
- When no groups are present, show an appropriate empty state that:
- Explains what group membership means in this context
- Provides a clear call-to-action to invite groups (when permissions allow)
- Shows informative messaging when the user lacks permissions to add groups
Design considerations
- Work with UX to design empty states that follow our pattern guidelines
- Consider different empty state variations based on:
- User permissions (can/cannot add groups)
- Project/Group visibility settings
- Whether group additions are disabled at the instance level
Technical approach
- Modify the existing tab rendering logic to always show the Groups tab
- Implement empty state components that respond to permission context
- Ensure consistency across both Project Members and Group Members interfaces
Success criteria
- Groups tab is always visible in member management interfaces
- Empty states provide clear, actionable guidance
- Implementation follows established GitLab design patterns
Related MR: !218547 (merged)
Design reference: https://design.gitlab.com/patterns/empty-states
Edited by 🤖 GitLab Bot 🤖