Essay
In Praise of Slow Interfaces
Software has never been faster, and we have never felt more rushed. A case for the deliberate pause — and for treating a reader's attention as the scarcest resource in the system.
There is a particular kind of tiredness that comes from using well-optimized software. Everything responds. Nothing waits. The list refreshes before you have finished reading it, the draft saves before you have finished the sentence, and the notification arrives before you have decided whether you wanted it. By any engineering measure this is a triumph. By any human measure it is exhausting.
We have spent two decades treating latency as the enemy, and we were right to. But somewhere in that campaign we collapsed two different ideas into one word. Responsiveness is a property of the system; pace is a property of the experience. Optimizing the first to its limit does not automatically improve the second, and past a certain point it actively degrades it.
The cost of instant
An interface that answers instantly removes the small interval in which a person notices what they are doing.Friction is not the same as difficulty. Good friction is legible and proportionate; bad friction is arbitrary. Readers forgive the first almost entirely. That interval is where second thoughts live. Remove it and you get a system that is very good at executing intentions the user never quite formed — the accidental send, the archived thread, the purchase confirmed with a thumb still in motion.
The problem is not that the machine is slow. The problem is that the machine is fast and we are not, and the interface has to hold both facts at once.
Ellis Prakash, Notes on Interaction Tempo, 2019
Speed is not the goal. Confidence is the goal, and speed is only one of several ways to buy it.
Three thresholds
The useful frame here is not a single latency budget but a set of perceptual thresholds. They have been stable in the human-factors literature since the sixties, and they have survived every hardware generation since, because they describe people rather than processors.1
Most bad waiting experiences are not too long — they are unaccounted for.Skeleton screens work for the same reason a laid table works. Both promise a specific shape of thing arriving soon. A four-second operation with a determinate progress bar reads as competent; a two-second operation with an indeterminate spinner reads as broken.
Designing the pause
Let the pause carry meaning
A transition that traces where a thing came from teaches the structure of the application. One that simply fades teaches nothing. The motion is a sentence about the relationship between two states, and the two hundred milliseconds it takes to say it are not lost time.
/* Motion is a courtesy, not a requirement. */
.panel {
view-transition-name: panel;
transition: transform 240ms cubic-bezier(.2, .7, .2, 1);
}
@media (prefers-reduced-motion: reduce) {
.panel { transition-duration: 1ms; }
}Let the pause hold the door open
Undo is the cheapest speed there is.The window only has to outlast the moment of realisation. Five seconds catches almost every misfire; thirty seconds catches almost nothing more. It lets the interface stay fast where speed is pleasant while keeping the consequence reversible for a few seconds afterward. The reader gets instant response and a way out.
In practice
In review, the questions that tend to be productive:
- Which band? Classify each operation against the thresholds before optimizing it.
- Is this reversible? If yes, be fast and offer undo. If no, be deliberate and say why.2
- What does the wait say? Replace the spinner with a shape, a count, or an estimate wherever that information exists.
- Measure the operation.
- Classify it against the thresholds.
- Spend the speed deliberately.
The interfaces that feel best to use are rarely the ones that respond fastest across the board. They are the ones where the tempo is legible. That legibility is the real deliverable. Speed is just one of the materials.