Speed is a feature. Not a nice-to-have, not a performance metric for engineers — a core element of user experience that directly affects engagement, task completion, and perceived quality. In 1982, Walter J. Doherty and Ahrvind J. Thadani published research at IBM showing that system response times under 400 milliseconds kept users in a state of productive flow, while responses over 400ms caused users to disengage, lose their train of thought, and work less efficiently. The threshold they identified has since become a benchmark for interface responsiveness.
The Psychology
The psychology behind it is about cognitive continuity. Human attention is not a spotlight that stays fixed while waiting. It drifts. When a system takes more than 400ms to respond, the user's attention has already begun migrating to other thoughts. They start wondering if their click registered, checking if they're connected, or simply losing the mental thread of the task they were executing. Under 400ms, the response feels instantaneous — the system feels like an extension of thought rather than a separate entity with its own schedule. Above that threshold, the seam between user intention and system response becomes visible and disruptive.
In Product Design
The practical challenge is that not every operation can genuinely complete in under 400ms, particularly those involving network requests, database queries, or heavy computation. The design response to this is perceived performance — the set of techniques that make wait times feel shorter than they are. Skeleton screens show the structure of content before the content itself arrives, so the user's brain begins parsing the layout while data loads. Optimistic UI updates assume the operation will succeed and update the interface immediately, rolling back only if an error occurs. Progress indicators with smooth, believable animations maintain the sense of activity and give the brain something to process during the wait. Loading states that include contextual messaging ("Fetching your recommendations") feel faster than spinners with no context.
How to Apply It
The engineering and design teams need to collaborate on this. Designers should specify loading state designs for every screen that involves async operations — not just a generic spinner, but thoughtful skeleton layouts that match the incoming content. Engineers should prioritise perceived performance as a UX criterion alongside actual performance. Prefetching content the user is likely to need next, lazy-loading below-the-fold content, and caching frequently accessed data all contribute. The 400ms threshold is not just about fast connections — it is about designing the experience of waiting as carefully as the experience of arrival.
Why It Matters
When interfaces consistently exceed the Doherty Threshold, users interpret slowness as poor quality. A study by Google found that a one-second delay in mobile load time reduces conversions by up to 20%. Users who encounter slow interfaces trust the product less, report lower satisfaction, and are more likely to abandon tasks mid-flow. The threshold is not just an engineering target. It is a UX principle: the interface that responds faster does not just complete tasks faster, it creates a qualitatively different experience of using the product.
