Perhaps this is just a pet peeve of mine, but as a software pattern, I am generally annoyed with the extra interaction required by the typical “confirmation > validation > action” workflow that many apps utilize.
The workflow I’m talking about generally goes like this:
- User requests an action by clicking/tap in the UI.
- App asks user “Are you sure? [Yes/No]” or “Do [action]? [OK/Cancel]”
- User clicks “OK/Yes”
- App validates the action, making sure it has all the required data, etc.
- If validation failed, App reports errors to user – “Sorry, can’t do that because…”
This pattern sucks.
Lets start with the the step #2, the confirmation. If you are writing software that’s going to give the user a “Yes/No” type dialog, think hard about whether you really need to do ask. Assuming the user didn’t accidentally click the button, they have already expressed their intentions. These dialogs are typically attached to destructive actions, such as deletes. It might be right to ask the user in these cases, but if possible, I think it’s better to go ahead and do it and provide a way to undo in case of accidents.
Next, consider the order of the process. Particularly step #4, the validation. If a state may exist that would prevent the user from completing an action — such as required fields missing — do that validation before you prompt for confirmation of the action. It removes a considerable amount of friction from the UI if an error state exists. If you validate after the confirmation, and then present the error, you will be forcing the user to go though the confirmation step again after they have corrected the error. That is annoying for the user. How many times have you cursed at your computer, “YES, I really mean to do that!!!!”