“isn't that a secondary goal of a good #UX, to prevent sleepy people from making stupid mistakes?”

No. Three things:

1. It's a _primary_ goal to never cause unintentional loss of user data — it doesn't matter that’s triggered by the software or user behavior.

2. This goal does not just apply to "sleepy people," but to _all_ users at all times.

3. Users should not be accused of making "stupid" mistakes. Maybe "foolish" or "unfortunate" ones; but never "stupid.”

😎 https://hachyderm.io/@ffissore/116102951562021068

Federico Fissore (@[email protected])

Attached: 1 image These 2 options on #microsoft #outlook could use a bit more spacing. I've already trashed my whole archive once, and it wasn't funny. Yes, I was dumb, and sleepy, but isn't that a secondary goal of a good #UX, to prevent sleepy people from making stupid mistakes?

Hachyderm.io

That said, yes, destructive commands should always be spatially separated from non-destructive ones.

Further, any destructive action should ideally come with a proper Undo, or at least a confirmation dialog. And in that confirmation dialog, the destructive commands must be spatially separated from non-destructive commands. Here's a great, old-school example from BBEdit.

(This is yet more evidence that the stacked buttons in iOS-style dialogs on macOS are #UX/#IxD garbage, plain and simple.)

I've also seen a #UX/#IxD pattern in simple Cancel/Confirm dialogs, in which the Confirm action is destructive.

In those dialogs, the Cancel button is the primary CTA with the associated visual appearance. And it responds to both ESCAPE and RETURN keys, so you can't confirm the destructive action by inadvertently hitting RETURN.

One more detail: I've seen plenty of Cancel/Confirm dialog boxes for destructive actions in which the buttons' locations are reversed. That is extremely dangerous, because if the (destructive) Confirm button is now in the Cancel location, a user trusting their motor memory to instinctively hit the Cancel _location_ will actually trigger the Confirm _action_.

Yup, #IxD (i.e., #InteractionDesign) is pretty straight-forward once you understand the thinking behind it. But it is never trivial.