Experimental Design - Destructive Button

[kellylein]

What

In reviewing the deltas between the VADS and our Mobile components, we found that there is no Destructive Button variant within VADS. We did research into Design System best practices and found that utilizing a Destructive Button is common in mature Design Systems.

A summary of our research: Destructive buttons are commonly included in design systems, and I've found some that provide guidance around your concern with the color red. Most destructive buttons appear red in mobile apps, but there's a mix of solid red buttons and buttons that have red text. It's commonly recommended not to rely on red alone to convey meaning, but to also ensure the text clearly describes what will happen and to create additional friction before completing the action. In the mobile app, we currently use destructive buttons for cancelling appointments, removing contact info, and signing out of the app. I'm not sure signing out of the app should be using a destructive button, but based on what I've read, I think it makes sense for cancelling an appointment and removing contact info. For each of these buttons, I think the text clearly conveys what will happen, but just in case, we also display a confirmation message (native alert or action sheet) before completing the action. Based on what I've seen, my recommendation would be to keep the destructive button in the mobile app design system. Red destructive buttons are industry standard in mobile apps, and it would be unusual for users to see them in another color.

Happy to discuss more or walk you through the FigJam if that'd be helpful.

Purpose

Signals to the user that this action permanently removes information.

Usage

A destructive button can be used any time the action being taken cannot be undone, such as cancelling an appointment.

Behavior

Describe the key interactions for this component, calling out any specific considerations for mobile.

Examples

See the FigJam

Accessibility

Though the destructive button is red in color, it should also be made clear in the copy that this is a destructive action so as not to rely only on the button color.

Guidance

https://department-of-veterans-affairs.github.io/va-mobile-app/design/Components/Buttons%20and%20links/Button/#differences-with-vads

Research (optional)

See the FigJam

Code (optional)

Include any existing code.

Next steps

You may present your work to the Design System Council at an upcoming meeting. If you do not or cannot attend the Design Council Meeting, you can opt to get an asynchronous approval.

Submit requests to join an upcoming Design System Council meeting in #platform-design-system.

During the meeting, the Design System Council Working Group will evaluate the request and make a decision.

If your request is approved, you can add your component or pattern to the system. If you have any questions on how to add your component or pattern to the system, please reach out to the Design System Team at #platform-design-system.

[caw310]

@kellylein Are you available this Friday, Feb 9 at 1pm ET to attend the DSC meeting to talk about this? If so I can add this to the agenda and will send you an invite to the meeting.

[briandeconinck]

Noting here one item we didn't have a chance to discuss in the DSC meeting, which I posted in Slack:

On the destructive button discussion in the DSC meeting, I'd propose that the destructive button guidance explicitly require a confirmation step when we're discarding user-submitted data, along the lines of the example given in the files pattern. This doesn't necessarily fall under WCAG 3.3.4 in every case but it definitely lives in the same neighborhood.

[humancompanion-usds]

@caw310 - Can you post the notes from DSC for this one in this issue? Thanks.

[caw310]

Here is a link to the DSC meeting notes. https://docs.google.com/document/d/1JOnY9jsXds2o0RNSNvUuRYCUPoa-A0zD1WDp-lojgiY/edit?usp=sharing