Response-time limits: three clocks, and the states between trigger and result

What it is for. Deciding how fast an interaction must answer, and what to show when it cannot answer fast enough, so waiting time is engineered instead of endured.

The three limits (Nielsen 1993). 0.1 seconds feels instantaneous; 1 second keeps the user's flow of thought unbroken; 10 seconds is the limit of keeping attention on one unattended wait. Each step is roughly 10x the previous one: 0.1, 1, 10. They are three different clocks in the human, not three points on one scale: 0.1s is perception, 1s is thought, 10s is attention.

Where the numbers come from. 0.1s traces to the perceptual cycle of about 100ms in the Model Human Processor (Card, Moran, and Newell 1983): feedback inside that window is registered as the result of your own action, so the object feels directly manipulated; past it, the user feels a system reacting after the fact. 1s is the span a train of thought holds without effort. 10s is how long attention stays on one thing nobody is feeding. These are measured regularities, not theorems: they cannot be derived from first principles, only measured, and the numbers carry the usual experimental spread.

The Doherty threshold (400ms, Doherty and Thadhani 1982). When system response fell below about 400ms, IBM measured a jump in user productivity, not a proportional gain: below the threshold users never enter a waiting mode and keep a continuous working rhythm; above it they wait, switch away, and the rhythm breaks. 400ms sits inside the 0.1 to 1s band and is the engineering sweet spot: reaching 0.1s everywhere is unnecessary, but getting under 400ms already captures most of the flow benefit.

The states between trigger and result. The numbers themselves are thin: once known, they are known. The depth is that perception can be engineered. Between a trigger and the final result, intermediate states can be inserted to manufacture the feeling of responsiveness. Three kinds, each cheating a different clock:

1. Acknowledgement states: the button changes colour, the selection highlights, a spinner appears. They cheat the 0.1s causality clock: the user asks only whether the system heard them, not for the result.
2. Progressive and streaming states: skeleton screens, structure first with content filling in, tokens arriving one by one. They cheat the 10s attention clock: every new piece of information re-anchors attention, so the clock restarts.
3. Optimistic states: the final result is shown before it is true, then reconciled, like a like turning red instantly or a message appearing in the chat before the server confirms. They bet that most operations succeed, so no waiting is needed at all.

The rule for intermediate states. Every intermediate state must move monotonically forward and never contradict the final result. A progress bar that runs backwards, a skeleton that never fills, an optimistic update visibly rolled back: once the fabrication breaks, it feels worse than honest waiting. And there is a ceiling: intermediate states buy time, they do not create it. A job that takes 30 seconds cannot be papered over; it must be restructured to run in the background and notify on completion.

The step shape is a resource rule. Because the payoff is cliff-shaped, not linear, 600ms to 400ms is worth far more than 400ms to 200ms: the first crosses a cliff, the second only polishes flat ground. That decides where optimization effort goes.

Worked case: the Lucerna reader. Tapping a word for its definition is local data: target 0.1s, and definitely under the 400ms Doherty threshold, or the reader's sentence parsing breaks. Circle-select with an AI reply cannot be fast, so it gets the full choreography: an acknowledgement within 1s (highlight, spinner, thinking indicator), token streaming so attention re-anchors, and past 10s, progress plus permission to keep reading. Skeleton screens hold the layout's attention in the meantime.

Transfer. The same three clocks govern every interaction in fitts-law and hicks-law territory: Fitts sizes the target, Hick sizes the choice, and these limits size the wait. A header that is fast to hit and fast to choose can still fail if its answers arrive past a clock.

Kin. fitts-law, hicks-law

Agent audit checklist: read this node, then check an interface against every line, and report each item with evidence.

1. Measure the interaction's real latency distribution (p50, p95), not its best case, and name which clock it falls under.
2. If it crosses a clock, which intermediate state applies: acknowledgement, progressive or streaming, or optimistic?
3. Does every intermediate state move forward and agree with the final result? Name any state that could contradict it.
4. If the job exceeds about 10s even with states, is it restructured to background plus notification?
5. Where does optimization effort go: which crossing buys a cliff, and which only polishes flat ground?