Two apps on my phone handle the same kind of action in opposite ways, and both of them are wrong.
The first confirms things it has no business confirming. The second will let me do something I can genuinely never take back with a single, unguarded tap. Neither has stopped to ask the question that actually matters, which isn't whether the action is safe or fast but how explicit it should be — how much friction, ceremony and certainty to put between me and the thing happening.
That question is a dial, not a switch. At one end everything is implicit: the app just does the thing, instantly, and never mentions it. Cmd-S has quietly disappeared from my life, because Notion and Google Docs save on every keystroke and I've stopped thinking about saving at all. You swipe an email in Gmail and it's archived before your thumb has left the glass. At the other end everything is explicit: GitHub won't delete a repository until you've typed its full name into a box, one character at a time, like a small act of penance. Most interactions sit somewhere between those two poles, and choosing where is one of the more consequential decisions in an interface that no-one ever writes down.
The dial
Here's a single delete, sitting at four different points on that dial. Same action, same project, wildly different amounts of ceremony. Try each one.
Gone at once, with a four-second way back. The friction is optional, and only after the fact.
Instant is the implicit end. One tap, gone, no questions asked. It feels wonderful right up until the moment it's the wrong tap, and then it feels like a trapdoor. Type-to-confirm is the explicit end. It's slow and faintly insulting to your competence, and that's the entire point of it — it exists for the actions where being slowed down is the feature, not the bug. The two in the middle are where most software actually lives, and where most of it gets the decision wrong.
Match the friction to the stakes
The rule I keep coming back to is that the friction should scale with the cost of getting it wrong, multiplied by how often someone is going to do it. A frequent, cheap, reversible action wants the implicit end. Archiving is a good example. I archive forty emails a day and I would riot if each one asked me to confirm. A rare, expensive, irreversible action wants the explicit end, and that's the one place the type-the-name ceremony earns its keep.
The failure I see most is picking one philosophy and applying it to everything with the same word in the label. A team decides they confirm destructive actions, and now every button that says delete gets the same dialog, whether it's deleting a draft or deleting a customer's account. The trouble is that a confirmation you've clicked through two hundred times stops being a safety measure and becomes a reflex. By the time you reach the one dialog that genuinely mattered, your thumb has already dismissed it out of muscle memory. Confirm everything and you've trained people to confirm nothing. Confirm nothing and you've handed them a loaded gun and told them to be careful.
Undo is the best seat on the dial
The middle spot I'd defend hardest is undo — the action happens immediately, no dialog, no ceremony, and a small time-boxed toast offers a way back. Gmail's Undo send, which is really a short send delay wearing an undo costume. Linear removing an issue and leaving the escape hatch sitting in the corner for a few seconds. It's implicit in the moment and explicit as a safety net, which means you get the speed of no confirmation and the safety of one, and you only pay for it if you actually made a mistake.
That last part is the whole reason I like it. A confirmation dialog taxes everyone, every single time, up front, to catch the rare error. Undo taxes only the person who erred, and only in the seconds after they erred. The friction is optional and it arrives after the fact, which is the most humane kind of friction there is. A good number of the confirm dialogs I've built over the years would have been better as an undo, and I only worked that out well after shipping them.
Undo has a ceiling, and it's worth being honest about it. It only works when the thing can actually be reversed. You can delay a sent email, but you cannot un-transfer money or un-drop a production table, and no amount of toast will save you there. For the genuinely irreversible and genuinely catastrophic, the explicit end stops being an insult and starts being a seatbelt. The friction of typing out a database name is nothing measured against the cost of dropping the wrong one.
Where this leaves me
The setting is invisible when it's right. Nobody notices a well-judged autosave or a well-placed undo — they just get on with the work, unbothered, which is exactly the point. You only ever notice explicitness when it's wrong: the confirmation that treats you like you've never used a computer, or the trapdoor that quietly swallows an afternoon of work.
So I've stopped thinking of it as a house style and started thinking of it as a question I owe every action, one at a time. The question is small. How much would it cost to get this wrong, and how often will someone do it. Answer that one honestly and the right amount of ceremony mostly places itself.