Sometimes friction is your best friend

The smoothest systems aren’t always the best ones. Sometimes the pause, the confirmation dialog, the friction that makes you slow down—that’s not poor design. That’s the system being honest about what’s actually happening.

I watched someone try to register their device three times before it worked. Each time, the system asked: Are you sure? Is this the right account? Should we send a confirmation code?

It felt annoying. Then I realized: those pauses prevented a mistake that would have locked them out completely.

We worship frictionless experiences. One-click ordering. Seamless checkout. “Just works.” The best interface is no interface. Remove every obstacle between intention and action.

But friction isn’t always an obstacle. Sometimes it’s a decision point disguised as an inconvenience.

When friction does work

Good confirmation dialogs don’t ask “Are you sure?” They ask “Are you sure you want to delete all 47 files?” The first is noise. The second forces you to notice what you’re actually doing.

The difference is whether the friction lives at a real decision point or just covers someone’s liability concerns.

I’ve seen this in writing tools. The ones that make publishing too easy result in more output, but not necessarily better output. You hit publish before you’ve thought through whether this idea is actually ready.

Constraints force consideration. A system that makes you manually move a file from drafts to published isn’t adding busywork—it’s creating a moment where you have to decide: is this actually done?

The /close skill I built does this on purpose. It requires work logs to maintain a 50/50 balance between technical details and reflective insight. That’s harder to write. That’s the point.

Without that friction, I’d log “changed three files” and move on. The constraint filters “I changed files” from “I changed files and here’s what that reveals about our assumptions.”

When friction reveals truth

Format conversion is inherently lossy. When you move a document from one system to another, something doesn’t translate. Headers become plain text. Links break. Formatting disappears.

You could hide that. Make the conversion “seamless.” But then users discover the problems later, when they’re harder to fix.

Better to show the friction. “We can’t preserve these three things. Here’s what will change.” The pause lets you decide if that’s acceptable before you commit.

This is why some systems show you progress bars even when they could hide them. The bar isn’t just feedback—it’s making you notice that something complex is happening. That the file you’re uploading is being processed, validated, stored in three different places.

Hiding that makes the system feel fast. Showing it makes the system feel honest.

The automation question

The strongest argument against friction is automation. Why make humans do something a machine could handle? Why force manual steps when you could remove them entirely?

Fair question. But automation has a downside: it removes decision points along with the busywork.

I’ve seen deployment scripts that work perfectly until they don’t. No friction, no pause, just “deploying…” and then production is down because nobody noticed the test suite failed.

Manual deployment has friction. You have to type commands. Review output. Confirm each step. That’s slower. It’s also a series of checkpoints where you can catch mistakes before they cascade.

The art is distinguishing between friction that protects decision points and friction that’s just inefficiency. One prevents disasters. The other wastes time.

What honest systems look like

Honest systems don’t hide complexity—they expose it at the right moments. They make you slow down when slowing down matters. They’re smooth where smoothness is just about efficiency, and bumpy where bumpiness forces you to think.

The password manager that makes you type your master password instead of using biometrics for high-stakes operations. The git workflow that makes you stage changes before committing. The confirmation screen before sending to 10,000 people instead of 10.

None of these are accidents. They’re designed pauses.

The bad friction is different. It’s the forms that make you re-enter information they already have. The extra clicks that serve no purpose. The approval chains that exist because nobody questioned whether they’re still needed.

That’s friction as artifact, not friction as design.

The test

When you encounter friction in a system, ask: Is this making me think about something I should be thinking about? Or is it just making me wait?

If it’s forcing consideration at a decision point—keep it. If it’s just slowing you down everywhere else—remove it.

The goal isn’t to eliminate friction. It’s to put friction exactly where it belongs: between you and the decisions that matter.

Sometimes the smoothest path leads you right off a cliff. Sometimes the system that makes you slow down is doing you a favor.

The confirmation dialog that saved you from a mistake you were about to make? That friction was your friend.