Mycelium

III · Trust

The Second Time You Delete Something

Trust is learning a thing once and never having to learn it again

The first time someone deletes a customer in a product I've worked on, here's what they meet. A confirmation, with words that say what's about to be lost and a button that looks like it means it. They click. The dialog closes, the row leaves the list, not instantly, but visibly, so the eye can follow it out. A small bar appears: Customer deleted · Undo. Eight seconds. Then it's gone for real. If anything had failed along the way, the dialog would have stayed open and said so in place, so there was never a moment of not knowing whether the deletion happened.

That's one interaction, and on its own it's just decent craft. The interesting thing is what happens the second time they delete something, anywhere in the product. A project. A team member. An uploaded file. They already know. There'll be a confirmation. There'll be a way back for a few seconds. "Deleted" will look and feel like it did before. They don't brace. They don't read the dialog as carefully. They've stopped checking.

That not-checking is the thing I'm after. It isn't satisfaction with one good screen. It's accumulated knowledge about how the product behaves, and accumulated knowledge is what trust is made of.

The design system nobody writes

Most teams have a visual design system. Colors, type, spacing, components, all documented, tokenised, enforced. The button looks the same everywhere. Good.

Almost nobody has written down the other one: how the product behaves. What happens when you submit. What happens when you delete. Whether there's an undo. What an error looks like and where it appears. And without that, a product that's visually immaculate can be behaviourally incoherent: one form answers with a toast, deleting in one place asks for confirmation and in another just does it, sending a message produces nothing at all. Each screen was designed on its own, by whoever had it that week.

The person experiences this as unreliability they can't name. Not broken. Unpredictable. And unpredictable erodes trust slowly and completely, because every interaction has to be approached fresh.

Same kind of action, same shape of answer

The way out, as I practice it, isn't to make every interaction identical. It's to notice that actions come in kinds, and to decide how each kind behaves once, before designing any particular screen.

The kinds are roughly these, though yours may differ. Actions that destroy something, permanently or nearly. Actions that create something. Actions that change something that already exists. Actions that move you somewhere. Actions the system does on your behalf in the background. Actions that confirm or approve, which often carry a small sense of accomplishment. And cutting across all of them: can it be undone, or not?

For each kind, there are a handful of things to decide. Does the system pause and ask first? What's the complete sequence from click to resolution? How loud is the answer? If it can be undone, for how long, and how? What happens when it fails? Decide those for destructive, and every destructive action in the product inherits the decision. The copy changes, the animation adapts to the container, but the shape is the same, which is why the second deletion feels like the first.

Then the step that almost never happens: write it down, in plain words, in a document a new designer or developer could read and know how the product responds to every kind of action without opening a single screen. A behavioral decision that lives in one person's head gets re-made differently by the next person on a different day. That's how inconsistency happens even on teams with beautiful visual systems.

Consistency isn't sameness

A delete confirmation on a phone might be a bottom sheet instead of a dialog. The undo bar might sit at the bottom rather than the top. The exit animation might differ. None of that breaks anything, because the promise is behavioral, not visual: there was a gate, there's a way back, failure is shown in place. Adapt the form to the context freely. Change the behavior between contexts and you've broken the thing the person was relying on.

Features are states, not buttons

A habit that helps me here: I try not to think of a feature as an action. "The user can extend their session" is a button. "The agent is in a session with a customer, and that session has a lifecycle" is a world the person is living in while they work. Map the states: how you enter each, what you can do in it, how you leave, what other people see while you're in it. The behavior falls out of the states far more reliably than it falls out of a list of buttons.

And the trigger for any of it is never the button. Nobody clicks "extend" because the button exists. They click because they're mid-conversation with a real person and the thought am I about to lose this arrived. Design for the thought and the button finds its behavior.

The patterns you didn't write

There's a wider promise sitting under your own. Pull to refresh. Swipe to delete. Escape closes the dialog. Ctrl-Z undoes. People spend most of their time in other products, so they arrive at yours already trained by all of them; that's Jakob's law, and it means those behaviors are promises you inherited whether you wanted them or not. Break one and you're inconsistent not with your own system but with the person's whole model of how software works. The honest move is to name the inherited patterns and either keep them or deviate on purpose, for a reason you can say out loud. Deviating because nobody thought about it is the most avoidable friction there is.

Where this bends

A written behavioral system can calcify. The first version of the delete sequence is a hypothesis, and if watching people shows the undo window is too short or the confirmation is in the way for a trivial item, the document should change, not the people. Consistency is in service of trust; the moment it starts costing trust, it's the rule that's wrong.

Questions to carry

(The Behavioral Audit, and the action kinds with their five decisions, are in the Field Kit.)