Under 400 milliseconds, work becomes a conversation.
Walter Doherty and Ahrvind Thadani’s 1982 IBM research: when a system responds in under 400 milliseconds, productivity soars — the user and the computer stay in the same train of thought. Paired here with the classic response-time limits every interface still lives by.
Walter J. Doherty and Ahrvind J. Thadani were IBM researchers studying the economics of interactive computing. Their 1982 paper, The Economic Value of Rapid Response Time, overturned the era’s assumption that two-second responses were good enough — productivity rose sharply as responses dropped below 400 milliseconds.
The finding reframed system speed as an economic argument: faster machines paid for themselves in recovered human attention. Decades later the same threshold shows up in web performance budgets, and Jakob Nielsen’s response-time limits carry the framework forward.
Productivity soars when a computer and its users interact at a pace — under 400 milliseconds — that ensures neither has to wait on the other. Below the threshold, work feels like a conversation; above it, each pause breaks the user’s train of thought and errors climb.
Doherty and Thadani measured transactions per hour as response time fell. The curve isn’t linear — under 400ms, users stop batching their thinking around the machine’s pauses and productivity jumps.
Jakob Nielsen’s three limits sit alongside Doherty’s threshold: 0.1 seconds feels instant, 1 second keeps the flow of thought, and 10 seconds is the outer edge of attention — past it, users switch tasks.
When the system can’t answer in 400ms, it can still acknowledge in 400ms. Skeleton screens, pressed states, and instant local echo make a slow operation feel responsive — perceived speed is a design material.
Commit the change on screen before the network confirms it. The message appears in the thread, the toggle flips, the item files itself — and the system reconciles behind the scenes. The user never waits for a round trip.
No single delay kills a workflow — the accumulation does. A 700ms search, a 900ms filter, a 1.2s save: across a working day the pauses add up to broken concentration and batched, error-prone work.
Treat 400ms the way you treat a visual spec. Give every interaction a budget, measure the slowest real-world path — not the demo machine — and spend engineering time where users actually wait.
Models take seconds, not milliseconds. The threshold doesn’t bend — so the interface has to spend the wait honestly.
A model that takes eight seconds violates every limit on this page — unless it streams. Tokens appearing at reading speed keep the user inside the 400ms conversation even while the full answer is seconds away.
The prompt should land instantly — echoed in the thread within 100ms — while the model works. The threshold governs the acknowledgment, not the answer. Dead air after a send is the one unforgivable AI latency.