Doherty Threshold, 응답이 400ms 이하면 생산성이 폭발한다

한 줄로

1982년 IBM의 한 연구가 단언했습니다. 시스템이 0.4초 안에 응답하면 사용자는 생각의 흐름을 잃지 않습니다.

어디서 왔나

1982년, IBM의 월터 도허티(Walter Doherty)가 IBM Systems Journal에 논문 "The economic value of rapid response time"을 실었습니다.

그가 측정한 것은 컴퓨터의 응답 시간이 사용자의 생산성에 미치는 영향입니다. 응답이 0.4초 이하로 빠를 때, 사용자는 흐름(flow)을 유지하면서 더 많은 일을 처리했습니다. 0.4초를 넘으면 흐름이 깨지고, 사용자가 다른 곳으로 주의가 분산됐습니다.

논문의 핵심 결론은 경영에 호소했습니다. 빠른 컴퓨터에 더 많은 돈을 쓰는 것이 사용자 시간을 절약해 결국 더 싸다는 것입니다.

이 임계값 0.4초가 후에 Doherty Threshold로 불리게 됐습니다.

지금 우리가 쓰는 방식

웹/모바일에서 이 임계값은 여전히 유효합니다. 더 세분화된 가이드라인이 후속 연구로 나왔습니다 (Jakob Nielsen):

• 100ms 이하: 사용자는 "즉각적"이라 느낍니다. 직접 조작감.
• 1초 이하: 사용자의 흐름 유지. 약간의 지연은 인식되지만 작업은 계속됩니다.
• 10초 이하: 사용자의 한계. 그 이상은 다른 일을 하기 시작합니다.

대응 방법:

• 즉각적 피드백: 버튼 누름 시 시각적 변화 (active state).
• Skeleton screen: 로딩 중에도 무언가 보입니다.
• Optimistic UI: 서버 응답 전에 일단 화면에 반영합니다.

바이브 메이커가 챙길 한 가지

본인 앱의 핵심 동작에 대해 응답 시간을 한 번 측정해 봅시다. 400ms를 넘는 동작이 있다면 거기서 사용자가 흐름을 잃고 있을 가능성이 높습니다. 서버 응답을 못 줄이면 시각적 즉시 피드백으로 인지된 응답 시간만이라도 줄여야 합니다.

관련

Skeleton screen · Optimistic UI · Flow