Deletion flow design audit
Problem
We are proposing an improved deletion flow that would better separate the actions to schedule an item for deletion, and the actual deletion itself. With this in mind, we want to investigate whether any additional UX improvements should be made to ensure users can:
- Schedule content for deletion
- Find content that is pending deletion
- Restore items (within a specified time period) that are pending deletion
- Be informed when a project or group they are managing has been marked for deletion
- Have consistent messaging and warnings in place between groups and projects
To-Do
Review the current deletion flow and list any UX improvements necessary. A few known problems are already collected in &17168 (closed), so reviewing the issues there might help drive the direction.
-
Conduct a design audit on deletion flow with recommendations -
Create a design issue to capture the proposals (P0 - P1 priority) identified in this audit for the 18.1 milestone
TL/DR
GitLab's deletion audit found inconsistent flows across six user journeies with varying lengths, entry points, and feedback (only appearing in list views, not settings). Modal designs use different button text and contain misleading warnings.
My proposal: standardize with a three-step flow, differentiate deletion stages clearly, add universal notifications with undo options, and enable bulk operations with safeguards.
Deletion User Flow
There are 6 critical user journeys of deleting project/ group:
- Delete a project from projects list
- Delete a project from project detail
- Delete a group from groups list
- Delete a group from groups detail
- Delete a project from admin area
- Delete a group from admin area
User journey | Step 1 | Step 2 | Step 3 | Step 4 |
---|---|---|---|---|
1 | ![]() |
![]() |
![]() |
|
2 | ![]() |
![]() |
![]() |
![]() |
3 | ![]() |
![]() |
![]() |
![]() |
4 | ![]() |
![]() |
![]() |
![]() |
5 | ![]() |
![]() |
![]() |
|
6 | ![]() |
![]() |
![]() |
- Inconsistent flow length: 3 steps [list → delete modal → toast] vs 4 steps [detail → settings → delete modal → detail]
- Inconsistent end-state: List view vs pending deletion detail page
- Inconsistent feedback: Toast notification vs no feedback
- Inconsistent entry points: Dropdown menu vs settings page
- No differentiation: 1st vs 2nd delete actions use identical communication and feedback
- Missing functionality: No bulk deletion option, creating difficulties for non-admin users
- Missing functionality: No pending deletion in the admin area, "Delete" means "Delete forever"
Deletion Modal
Group deletion | Project deletion | Admin area |
---|---|---|
![]() |
![]() |
![]() |
- Inconsistent design patterns between admin/settings areas
- Different CTA button text across flows i.e. "Confirm" vs "Yes, delete project" vs "Delete project"
- Mixed modal titles: "Are you sure..." vs "Delete...", "Are you sure..." increases cognitive load
- False "cannot restore" warning despite admin restoration ability
- Inconsistent severity: generic (groups) vs detailed (projects)
- No severity difference in copy between 1st time deletion & 2nd time deletion
Deletion card
1st Deletion card | 2nd Deletion card |
---|---|
![]() |
![]() |
- "Delete immediately" didn't indicate the impact of the action
- The content on the card is overlapping with deletion modal
Deletion feedback
1st time deletion | 2nd time deletion |
---|---|
![]() |
![]() |
- Deletion feedback only presented when deleting from list page but not settings
Pending deletion banner
Pending deletion banner |
---|
![]() |
- Inconsistent copy pattern between banners
Email notification
Deletion email |
---|
![]() |
- The visual hierarchy can be improved by highlighting deletion date, projects details and explain the consequences
- No email notification 7 days prior to permanent deletion
Design proposal
-
[P0] Standardize Deletion Experience
- Create uniform confirmation modals with clear titles and button labels
- Add consistent deletion controls in all areas (lists, details, admin)
- Use a simple three-step flow everywhere: trigger → confirm → feedback
-
[P0] Differentiate Deletion Stages
- Visually distinguish between "Schedule for deletion" and "Delete permanently" across action, confirmation and feedback
- Create an impact level framework to communicate consequences at each stage
-
[P1] Enhance Error Prevention
- Implement toast notifications with undo buttons for all deletion flows
- Create a "Pending Deletion" view to manage scheduled deletions
- Ensure restore options at all state
-
[P2] Improve Notifications
- Redesign emails highlighting deletion dates and affected items
- Send 7-day warning notifications (email/in-app notification) before permanent deletion
- Add simple help text explaining the deletion process
-
[P3] Enable Bulk Operations
- Add multi-select in list views for managing multiple items
- Implement safeguards for bulk actions showing impact scope
Open questions
- If parent item is under pending deletion, should a child item be premaritally deletable and restorable?
- No
- Should we include group in the inactive tab at group level?
- Yes, there is issue to do it
- Can user undo a permanently deletion?
- Need technical person to answer this one