"Are You Sure?" vs. Undo: Design and Technology
This month’s column was going to be one of those tactical pattern ones, but it changed while I wrote it.
Every time I’m on a project with management of stuff in a list — which is most of them — there’s the ability to delete or remove items. The classic way is the guard condition, or an “Are you sure?” dialog:
These are actually pretty awful, perform poorly, and cause all sorts of context problems. Context? I can solve that! So years ago I switched to the same basic thing, but inline with the item:
Which seems good, but is oddly… not. Everyone prefers it, but performance is bad. So I’ve ended up simply always using undo:
Except, I don’t. And that’s where things changed a bit. See, undo is hard to do in database (and API/service) design, so: we cheat. It’s just marked-for-deletion, then when the page is exited properly, all marked delete actions are carried out. If it crashes, etc. then the system fails safe, and nothing is deleted.
This design works because I understand the technology. And it’s not a problem when developers actually read the specs. But way too much of the time, they look at the photo or see the story “undo” and panic.
Read the whole article Are You Sure? Versus Undo: Design and Technology at UXmatters: https://www.uxmatters.com/mt/archives/2020/03/are-you-sure-versus-undo-design-and-technology.php