Working in a team of 2, we were tasked with designing a feature which allowed users to gain control over their deleted data to reduce the burden on our support team.
Users in our product were accidentally deleting data. When this happened, the only path to recovery was contacting the support team to restore the records manually.
This created friction on both sides: users faced delays waiting on support, and the support team spent significant time on a repetitive, low-value task that should have been self-serviceable.
There was also a gap on the other end of the spectrum. Users who intentionally deleted data had no way to permanently remove it either. Users had to contact support for this request as well.
We conducted interviews with subject matter experts on the support team to understand the problem as detailed as we could. These conversations surfaced:
These interviews gave me enough signal to move forward without formal research, and helped me frame the design in terms of the support team's real-world workflow.
Because of the sensitivity of the actions (restoring/permanently deletion) and the need to sift through potentially a large amount of data, a multi-step wizard was the pattern we chose. With progressive disclosure and multiple steps, wizards force users to be intentional with their actions.
Users first identify which data table the deleted records came from. This reduces cognitive load in subsequent steps by filtering what's shown.
We present users with a clear binary choice: restore the records or permanently delete them. Presenting this as a dedicated step reduces complexity and ensures users are being intentional before reviewing records.
Users see the deleted records relevant to their selected table and action. They can filter to narrow down the specific records they want to affect before confirming.
This structure mirrors how the support team already handled requests mentally (what was deleted, from where, and what do we want to do with it), which helped ensure the flow felt intuitive to users familiar with the existing process.
Two major constraints affected our design: product rigidity and performance issues.
The product this feature lives in is technically rigid. The UI framework offers limited flexibility, and many components were not well designed to begin with. Also, the outdated nature and poor performance of the product forced us to use pagination to display the deleted records, rather than a preferable lazy load. This was a constraint that affected the implementation of our design.
The filtering experience in Step 3 was the most affected by this. The available filter components weren't built for this kind of use case. Pagination also made it difficult to communicate selected records across pages. Rather than pushing for a one-off solution that would have been expensive and stalled the project, I worked within the product's constraints to focus on:
These were major constraints. The filtering experience is functional, but not ideal. A future iteration with more engineering investment could meaningfully improve that step.
The feature shipped and gave users full self-service control over their deleted data for the first time. Early feedback from support points to a reduction in support tickets related to data restore requests.
What went well: The wizard was a great design choice. It gave users a clear, guided path through a complex action.
What I'd do differently: If there was a less demanding deadline, I would’ve pushed harder earlier for design exploration of the filtering component, even within the product’s constraints. The current solution works, but it's the weakest part of the experience and the most likely source of future user frustration. Better understanding of the constraints upfront would have prevented rework and created more time to explore better options.
What I'd want to validate: Usage data on where users drop off in the wizard, and whether the filtering step causes confusion. If drop-off is high at Step 3, that confirms the filtering experience needs investment.
