The UX of Slowing Down
How friction — designed well — can actually improve the way software feels to use.
Speed is the default value proposition of most software. Faster load times, quicker flows, reduced steps. Friction is the enemy.
And mostly, this is right. Nobody wants to wait for a page to load or click through five screens to do something they do every day.
But I’ve been thinking about the cases where slowness — or more precisely, intentional friction — makes software better.
The confirmation pause
There’s a moment in many apps where you’re about to do something irreversible — delete a file, send a message, submit a payment — and the app asks you to confirm. Sometimes this is done poorly: a generic “Are you sure?” that you’ve clicked through so many times it’s invisible.
But when it’s done well, it does something important. It creates a small pause. It gives you a moment to reconsider.
The best version of this I’ve seen is in apps that make you type something to confirm. Not a random string, but the actual name of the thing you’re deleting. The friction isn’t decorative — it forces you to read and acknowledge.
Deliberate loading
I’ve noticed that some apps add a brief artificial delay before showing results. Not because they need to — the computation is done — but because an instant result can feel wrong. It can feel like the app didn’t take your request seriously.
This is counterintuitive. We want fast apps. But there’s a difference between fast and immediate. An action that has weight should have some acknowledgment of that weight.
Pacing in reading experiences
Some reading apps default to a paginated view rather than scrolling. This is slower, by almost any measure. But pagination creates something scrolling can’t: a sense of finishing.
When you scroll endlessly, you never really finish a thing. When you turn a page, you’re done with that page. It’s a small thing but it matters over time.
What friction is actually for
I think the underlying principle is this: friction should match stakes. Low-stakes actions should be frictionless. High-stakes actions should have friction proportional to their weight.
The problem is that most software applies friction uniformly — or removes it uniformly. The thoughtful design is to ask, for each moment: what does the user need to feel here? Sometimes they need speed. Sometimes they need to slow down.