@xahteiwi
It depends a lot on the use case but there are a bunch of old ideas that are relevant.
Apple's HIGs from 30+ years ago told you never to put 'yes' or 'no' or 'okay' on dialog box buttons. The buttons should always be verbs or verb phrases. For example, don't do:
'Erase your disk?' [ No ] [ Yes ]
Instead, do:
'Erase the disk?' [ Do not erase ] [ Erase the entire disk ]
This means that even people who don't read the question do read the answer before selecting it. For very high stakes things, you can require people to type 'I wish to erase the entire disk and I know that this cannot be undone' or similar, rather than a button.
For slightly lower-stakes thing, people sometimes disable the proceed button in the dialog for a few seconds. This solves two problems:
- User clicks before reading.
- Dialog appears and the user aims to click on something else that happened to be below the dialog.
There's also Raskin's First Law: A program must not harm a user's data or cause a user's data to come to harm.
This means that you need to make these operations support undo. For erasing an entire disk, that's not feasible, but for most things it is. Don't delete things, move them to a to-delete area. This is why MacOS had a rubbish bin from the start: delete moved things, if you didn't mean to delete them there was a move-back (undelete) button.
For a lot of things, starting with a non-destructive model makes sense. For example, if your file format includes unlimited undo history, you can add a 'publish' button that gives you a new copy without undo history. That means that you never have destructive operations. Similarly, if you're running some semi-arbitrary code, do it in a sandbox, unconditionally. Don't ask people 'do you want to trust this probably malicious thing?' just treat it as malicious and sandbox it.