First, I received a linear ticket, which linked to a quality control issue described in Miro. Users were permanently deleting data in the platform mistakenly. These mistakes required Site Reliability Engineers (SREs) to reverse user action manually and contributed to a poor user experience.

After hearing repeated complaints from SREs, my product manager decided to reevaluate the thoughtful friction around permanent actions. She soon realized that throughout the product, the safeguard modals that provide thoughtful friction around permanent action were unclear and inconsistent. She determined that a redesign of the safeguard modal components was high priority.

Solution 1:
The most obvious solution was to not allow users to make changes that cannot be undone.
Solution 1 drawback:
Not allowing users to make changes that cannot be undone would contradict the function of the product. Users need to be able to adjust the data that they observe to best serve their needs.

Solution 2:
Allow users to reverse changes.
Solution 2 drawback:
Allowing users to reverse changes could impact results due to a gap in time. For data to be accurate, it needs to be collected continuously.

Solution 3:
Add thoughtful friction to permanent changes.
Solution 3 drawback:
Adding friction to user action contradicts my objective as a product designer. My goal is to empower users, remove roadblocks, and decrease friction—not add it.

‍

After evaluating all of the potential solutions, I decided that Solution 3 solved the problem with the least detrimental drawback. As such, I agreed with my product designer that I would keep and redesign the Safeguard Modal components.

For research, I conducted internal interviews with two SREs to gather more context about the problem. While I was not able to collect specific numerical data, I did learn from their estimates that reversals occur approximately 1x/week, but the experience can be devastating: A recent sales prospect deleted more than 50,000 metrics in error.

‍

I then conducted research about safeguard modals in general, and did a complete audit of safeguard modals throughout the product to understand best practices and identify the ways we were falling short.

Before sketching, I identified two potential variables for the component variations: 1. How much friction? and 2. How much context? I worked through the logic of the modal variations with a simple decision tree that grew more complex, the more I considered the potential options.

‍

After, I skipped wireframing and moved straight to a high fidelity mockup of a default safeguard modal, since Bigeye already had a default modal component and actually planned to ship a new version imminently. As such, I knew the basic structure of my designs, and didn't have to waste time sketching.

I came to my team design crit with a default design using our current modal UI, a design with our soon-to-be-shipped version 2 modal UI, a set of questions about how to stylize variations, and a few alternate designs in anticipation of any team pushback. As a designer, I always believe it is easier to discuss ideas and alternatives with a visual mockup on hand.

The team emphasized the importance of transparency, at least in the initial phases of the Bigeye product. Together we decided to include as much context as possible without confusing the message.

‍

After team input, I created a new version of the design UI and met quickly with Design Director to answer a few outstanding questions.

Next, my Product Manager and I scheduled a meeting with the engineer on our team. We walked through my safeguard modal designs and discussed the backend logic we envisioned.

According to the engineer, version 1 of my design would need to be amended due to some present backend limitations. Currently, it would be impossible to separate impacted objects by type. I went back to the drawing board and created both a V1 and V2 version of the designs.

‍

I also created a rough mockup of a future design that could be implemented once our component library included tooltips.

Now that the new destructive modals are live, we are going to track instances that users ask our team to reverse permanent actions in hope that they are rare if not nonexistent.

That said, the final version is in no way the North Star. Looking forward, I would love to implement and test the following:

-Using icons rather than bullet points as indicated in my design
-Presenting impacted objects as links to remove unnecessary friction
-Hiding impacted object names and only showing them as a tooltip or expanded list