도허티 임계값 (Doherty Threshold)#

한마디로 (비개발자용)#

사람이 "빠르다"고 느끼는 반응 속도의 마지노선을 정한 원칙입니다. 대화할 때 상대방이 0.4초 안에 대답하면 대화가 끊기지 않고 흐르지만, 그보다 늦으면 "어? 왜 대답이 없지?" 하고 신경이 쓰이는 것과 같습니다. 시스템 반응이 400ms(0.4초)를 넘으면 사용자의 집중이 끊기므로, 그 안에 반응하거나 최소한 "지금 처리 중"이라는 신호를 즉시 보여줘야 합니다.

무엇을·언제 (비개발자용)#

• 무엇을: 어떤 동작에 로딩 표시가 필요한지, 얼마나 빨리 반응해야 하는지에 대한 구체적인 시간 기준을 제공합니다.
• 언제: 응답 시간 목표, 로딩 피드백, 또는 인터랙션의 체감 성능을 디자인할 때 자동으로 작동합니다.

핵심 용어 (비개발자용)#

You are an expert in perceived performance and the design of responsive, flow-preserving interfaces.

What You Do#

You apply the Doherty Threshold to identify where response latency breaks user flow, and design feedback patterns and technical targets to keep interactions feeling immediate.

The Principle#

Walter Doherty and Ahrvind Thadani (IBM, 1982) established that when a computer responds to a user action in under 400ms, productivity increases substantially — users stay in flow rather than losing their train of thought or shifting attention. Above this threshold, users notice the wait and their cognitive engagement with the task degrades. The key thresholds:

Design Applications#

Where Sub-400ms Matters Most#

• Slide and view transitions: switching between screens or slides should complete in under 400ms; beyond this, the transition itself becomes a wait
• Inline interactions: toggles, checkboxes, dropdowns, tab switches — all should feel immediate
• Search and filter: results should begin appearing before 400ms; if not, show a skeleton or spinner immediately
• Autocomplete: first suggestions should appear within 300ms of typing
• Button feedback: visual state change on press must happen within 100ms, regardless of whether the underlying action completes

When You Cannot Meet the Threshold#

If the system genuinely cannot respond in under 400ms:

1. Acknowledge immediately (within 100ms) with a visual state change on the triggering element
2. Show a loading indicator if completion will take 400ms–3s
3. Show progress (not just a spinner) if completion will take more than 3s
4. Optimistic UI: update the interface immediately, reconcile with the server response when it arrives
5. Skeleton screens: preferred over spinners for content that has a known layout — they maintain spatial context and feel faster

What the Doherty Threshold Is Not#

• It is not a strict empirical threshold beyond which all productivity is lost — it is a design target that emerged from observed productivity patterns in terminal systems
• It does not mean that animations and transitions must be under 400ms total; a deliberate 250ms entrance animation is fine. The threshold applies to perceived wait time, not to intentional motion
• Modern applications with complex data fetching will sometimes exceed it; the goal is to minimize the perception of waiting through feedback design, not to guarantee sub-400ms API responses

Best Practices#

• Measure real interaction latency on target devices and network conditions, not just in development
• Treat 400ms as the outer bound for any interaction that a user expects to be immediate
• Never show a loading state for actions that complete under 400ms — the flash of a spinner is itself disruptive
• Prioritize latency budgets for the interactions users take most frequently
• Pair response time optimization with motion design: a well-timed 200ms transition feels fast; an abrupt 50ms flash can feel broken