Loading…
Loading…
Productivity soars when response times are under 400ms.
stellae.design
Productivity and engagement improve when systems respond fast enough to maintain cognitive momentum — roughly under 400ms. When responses are slow, users fall into 'waiting mode,' lose flow, and make more errors.
Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other.
Click each button and feel the difference in response time:
Below 400ms, interactions feel "instant." Above it, users consciously notice the wait. Try each to feel the threshold.
Instant feedback with optimistic updates
Actions feel immediate with skeleton screens during loading
Spinner-heavy interface with visible loading states
Every action shows a loading spinner, breaking user flow
The concept traces to IBM research by Doherty and Thadani on rapid response time and productivity. The psychological mechanism is disruption of flow — the state of deep engagement described by Mihaly Csikszentmihalyi, characterised by clear feedback and an uninterrupted sense of control. HCI response-time research consistently shows sub-second responsiveness is preferred, while delays harm performance and satisfaction.
Google Instant displayed search results as the user typed, with results appearing in under 100 milliseconds per keystroke. By keeping system response time well below the Doherty Threshold, the interaction felt like a conversation rather than a query-and-wait cycle. User engagement and searches per session increased measurably.
Figma renders design changes on the canvas in real time — moving objects, resizing elements, and changing properties all reflect instantly. This sub-400ms feedback keeps designers in a creative flow state where the tool feels like an extension of their thinking. Any perceptible lag would break the direct-manipulation illusion and disrupt the design process.
Many enterprise analytics platforms take 5-15 seconds to render reports after a filter change. Users lose their train of thought, switch to other tasks, or abandon the analysis entirely. The delay far exceeds the Doherty Threshold, transforming what should be an exploratory, iterative process into a frustrating wait-and-remember exercise.
VS Code maintains sub-100ms response times for typing, syntax highlighting, and autocomplete suggestions, even in large files. This responsiveness keeps developers in a flow state where they can think and code fluidly. The performance investment in the editor's core loop directly drives developer productivity and satisfaction.
• Treating '400ms' as a universal law regardless of context — complex operations will take longer.
• Adding animation as 'busy work' with no truthful progress information and no cancel/undo option.
• Faking speed instead of communicating honestly about wait times.
| Check | Good Pattern | How to Test |
|---|---|---|
| Core interaction response time | Primary user interactions (clicks, keystrokes, navigation) produce visible feedback in under 400ms, with a target of under 100ms for direct manipulation. | Use browser performance tools or custom timing instrumentation to measure time-to-first-visual-change for core interactions. Run tests on representative hardware, not just developer machines. |
| Loading state communication | When responses exceed 400ms, users see immediate acknowledgment (skeleton screens, progress indicators, spinners) that the system is working. | Throttle network speed in dev tools and verify that every action that could exceed 400ms shows a loading indicator within the first 100ms. No action should appear to do nothing. |
| Perceived performance optimization | Optimistic UI updates, prefetching, and progressive loading are used to maintain the perception of speed even when actual operations take longer. | Identify the five most common user actions and measure perceived response time (time until the UI reflects the change) versus actual completion time. Optimistic updates should close the gap. |
When work genuinely takes time (imports, ML inference, settlement), don't fake speed. Design truthful progress indicators, background processing, notifications on completion, and recovery options. You can't always be fast, but you can always be clear.
Was this article helpful?