Destructive button: Questions / Answers

[tbaker1026]

• What types of actions are considered destructive in your product or workflow?(deleting data, removing users, resetting settings)
• What are the consequences of the destructive action?
• Where do you currently use destructive buttons? (In modals, on cards, forms....)
• Do you use destructive buttons inline with other actions or separate from them?
• Do you always require a confirmation before executing a destructive action or is this optional?
• How do you differentiate destructive buttons visually?
• Do you use specific text on buttons?
• Do destructive buttons need different states? (loading, disabled, success, error)
• What feedback should users receive after a destructive action?
• Confirmation message, undo option, redirect?

Share any Figma use cases and the team you are on in your response

[tbaker1026]

From Ruben Sun -
We have a number of destructive action models in the 526 upon changing responses in key points in the form flow in:
toxic exposure page
choice to include a mental health statement

• 0781 file upload page
• types of trauma experience resulting in mental health conditions
• traumatic events experienced from military service
• behavioral changes experiences following traumatic events

We're using standard modals buttons to confirm the destructive actions.
Please keep us posted of any developments we should be aware of!!!

[rubensun]

See highlighted sections of the 526 with destructive actions in our form flow:

[rubensun]

There are also interaction flows in the 526 form flow mural as well

Example of a destructive action for a file:

Example of a destructive action for online form content:

[rubensun]

Separately, disability benefits pathways team conducted a review of how content was framed, and how selection and focus states and is looking to refine and finalize design changes in the next sprint to address the issues described in this ticket:
#119403

[Mottie]

In our 686c-674 form, we have an entry page that asks if you want to add or remove a dependent. Once within the flow (e.g. adding a dependent child), the first page, that isn't inside a list loop, includes a "Cancel adding children" button that redirects the Veteran back to near the beginning of our form when "Yes, cancel" is selected. Figma

[jfinnerty13]

Destructive actions live throughout profile, anywhere a user can remove information we trigger a modal.

User can click any of the remove buttons which will trigger the modal

Contact info page example

[Mottie]

I'm also working on a modal that appears within an array builder list loop. If you're entering data that appears to be a duplicate entry, a modal will appear on continuing past a page.

[jeana-adhoc]

so in this case, it's "Save and continue" that could trigger the modal based on logic?

[Mottie]

Yes, the "Save and continue" button triggers the modal if some conditions are met.

[JonathanPostMO]

I thought about this for a bit, and re: mobile usage—

I would design for user intent, not against their actions. UI should help prevent accidents while respecting a user's deliberate choices, matching the design's alarm to the action's risk (i.e. big red button = alarming, and used primarily for high risk actions).

To go a little deeper, I'd reserve red buttons exclusively for high-risk, irreversible actions with a high potential for regret. This applies when a user stands to lose significant value, like permanent data, hours of work on a secure message draft, or a real-world opportunity like canceling a difficult to book appointment. I don't know if we really have this use case, but for the users who have decided to delete their accounts, the red button would provide a final, deliberate confirmation—serveing their intent.

In contrast, I would use secondary styles for low-risk actions, even if they're technically "destructive" like clearing a form field. These actions are easily reversible and have low consequences. Using an alarming design in this context creates unnecessary friction. My framework for this is centered around providing safety where needed and efficiency everywhere else, respecting user's autonomy and helping them make decisions through semantic UI but also not impeding their decision making process.