Should a destructive action be hard to reach, or just hard to confirm?

Published Read 3 min read

On this page

Make a destructive action easy to reach and hard to commit, not hidden away where no one can find it. Guarding the moment of commitment, through a deliberate confirmation or a typed acknowledgment, protects users better than burying the action, because a hidden action frustrates the people with a legitimate reason to use it while a clearly visible but well-guarded one stays findable and still stays safe. The answer leans firmly toward findable but protected. The danger of a destructive action is not that people can see it. It is that they might trigger it by accident, and that is a problem you solve at the point of commitment, not by playing hide and seek.

The reasoning is that “hard to reach” and “hard to confirm” guard against different failures, and only one of them is the real risk. Burying an action assumes the threat is discovery, that if users cannot find the delete button they cannot misuse it. But the user who needs to delete something genuinely, to remove an account, clear a project, wipe a record, now has to hunt for the control, and every minute they spend digging is friction inflicted on legitimate use. Meanwhile burial does not even prevent accidents reliably, because once someone does find the action, it fires as easily as any other. Guarding the commitment flips this. The action sits where people expect it, so legitimate use is unobstructed, and the protection lives in the one place that matters: a deliberate step between intent and execution that an accidental tap cannot clear. The “bury dangerous actions deep so no one hits them” habit optimizes against the wrong failure and quietly punishes real users to do it.

Consider deleting a repository or a workspace. The buried approach tucks the delete option behind several unmarked menus, so the rare person who truly needs it spends ten minutes searching and the team wiki fills with “where is the delete button” questions, while it still deletes in a single click once found. The guarded approach keeps “Delete workspace” plainly in the settings where anyone would look, but the click opens a dialog that explains exactly what will be lost and asks the user to type the workspace name to proceed. The action is fully findable, so legitimate use is smooth, and it is genuinely hard to do by accident, because no stray tap will ever type out the name. Findable and guarded beats hidden and unguarded on both counts.

The exception worth naming is that this is about protecting an action the user is entitled to take, not about who is allowed to take it at all. Some destructive actions should be restricted by permissions or roles, kept away from users who have no business performing them, and that is a separate decision from how you guard the action for those who do. “Easy to reach” means easy for the right person to find, not exposed to everyone regardless of authority. There is also a calibration limit: the guard should match the stakes, so a serious deletion earns a typed confirmation while a smaller reversible removal needs only a light check, and piling maximum friction on every destructive act drifts back toward obstruction.

When you place a destructive action, keep it where users would naturally look for it and put your effort into the moment of commitment. Make the action plainly findable, then guard the commit with a confirmation that fits the stakes, a clear dialog for serious losses, a typed acknowledgment for the truly irreversible. Resist the urge to hide it, because hiding frustrates the people who need it without making it meaningfully safer. Keep destructive actions easy to reach and hard to commit, and you protect against the accident without punishing legitimate use.

Related posts:

  1. How do you animate a state change so it reads as cause and effect? You make a state change read as cause and effect by connecting the trigger to the result through continuity, of position, of shape, or of motion, so the user watches......
  2. How do you keep two designers’ work consistent without a system? Two designers stay consistent without a formal system through shared references, agreed conventions, regular sync and critique, and active reuse of each other's patterns. Consistency in this setting is a......
  3. What breaks when you design only for the two most common screen sizes? What breaks is everything you never checked: the widths in between your two snapshots and the widths beyond them. Designing to the most common phone and the most common desktop......
  4. When is hiding content on mobile the right call vs a cop-out? Hiding content on mobile is the right call when the content is genuinely lower priority in the mobile context and stays available somewhere, and a cop-out when it removes things......
  5. Why do placeholder-only form labels fail accessibility? Placeholder-only labels fail because the placeholder disappears the instant someone starts typing, sits at low contrast by design, and is not reliably treated as a field's name by assistive technology.......
  6. When is auto-playing content an accessibility problem vs fine? Auto-playing content becomes an accessibility problem when it moves, sounds, or changes for more than a moment with no easy way to pause or stop it, and it is fine......
  7. When is a full-width section right vs a contained, centered one? Choose full width when the content is meant to envelop the viewer and a contained, centered width when the content is meant to be read. That single distinction settles most......
  8. How do you keep a hero readable from phone to ultrawide? A hero stays readable across every width when you decouple the text's legibility from the background image's behavior. The mechanism is that an image and the type laid over it......
  9. Should you build a color system from one hue or several? Start from one hue and expand only when the product proves it needs more. A single-hue system, built from one color stretched across tints, shades, and a neutral ramp, reads......
  10. How much whitespace is too much before a layout feels empty instead of intentional? Whitespace becomes too much the moment it stops doing a job. The tipping point is not a pixel value, a margin token, or a percentage of the viewport. It is......
  11. When does a second typeface add hierarchy vs just add noise? A second typeface earns its place only when it draws a clear functional line, the most common one being headings against body, and it becomes noise the moment it decorates......
  12. Should dark mode be a true inversion, or designed separately? Dark mode should be designed separately, as its own deliberate theme, not produced by inverting the light one. A literal flip is tempting because it looks like a single switch,......
  13. Why can shipping one more feature make a product feel worse to use? Shipping one more feature can make a product feel worse because every feature adds interface, choices, and surface area, and that accumulation crowds the core even when the new feature......

Leave a comment

Your email address will not be published. Required fields are marked *