[📕] 10장. 도허티 임계 - 처리 시간에 관한 피드백(0.4초)

10장. 도허티 임계

 
컴퓨터와 사용자가 서로를 기다리지 않아도 되는 속도(0.4초 이하)로 인터랙션하면 생산성은 급격히 높아진다.
 

[핵심 요약]

- 사용자의 주의가 분산되는 것을 막는 동시에 생산성도 향상시키려면 시스템 피드백을 0.4초 이내에 제공하라.
- 반응 시간을 개선하고 체감 대기 시간을 줄이려면 체감 성능을 활용하라.
- 애니메이션은 로딩이나 프로세싱이 진행되는 동안 사람들의 시선을 끄는 한 가지 방법이다.
- 설사 정확하지 않다고 해도 진행표시줄을 보여주면 사용자는 대기 시간에 좀 더 관대해진다.
- 실제 작업이 훨씬 빨리 완료되더라도, 의도적으로 작업 완료를 늦게 알리면 체감 가치를 높이고 신뢰를 형성하는 데 도움이 되기도 한다.

 
제품이나 서비스를 처음 로딩하는 데 걸리는 시간, 인터랙션에 반응해 피드백을 제공한 속도, 다음 페이지를 로딩하는 데 걸린 시간 등 시스템의 반응 속도는 전체 사용자 경험을 좌우하는 열쇠다. 

시스템이 느리게 반응하면 인터페이스를 사용하는 사람의 생산성도 떨어진다. 반응이 즉각적이라고 느끼려면 0.1초 이내여야 한다. 0.1~0.3초 사이의 지연은 맨눈으로 감지되는 수준이어서 사용자는 해당 시스템이 자신의 통제에서 벗어나고 있다고 느낀다. 지연이 1초 이상으로 늘어나면 사용자는 집중하기가 어려워지고 작업 수행에 필요한 정보를 놏치기 시작하므로 생산성은 필연적으로 감소한다. 그 결과 작업을 이어가는 데 필요한 인지 부하가 커지고 사용자 경험은 전체적으로 나빠진다.
 

---

 

[사례]

 
처리 시간이 도허티 임계가 규정한 시간(0.4초이하)보다 더 많이 걸려도 딱히 개선할 방법이 없을 때도 있다. 이럴 때는 필요한 프로세싱이 수행되는 동안 사용자에게 처리 시간에 관한 피드백을 주면 좋다. 피드백을 받으면 사용자는 웹사이트나 앱이 실제보다 더 빠르게 작동한다고 느낀다.

 
1) 뼈대 화면
콘텐츠가 로딩되는 동안 콘텐츠 영역에 임시로 자리표시자 블록을 표시하는 것을 가리키는데, 이 기법을 쓰면 사이트가 더 빨리 로딩되는 것처럼 보인다.

 
2) 블러 업 효과
실제 큰 이미지를 표시할 공간에 먼저 아주 작은 크기로 이미지를 로딩한 후 크게 확대해 표시하는 기법이다. 이때, 저해상도 이미지가 커짐에 따라 이미지가 픽셀 단위로 깨지고 노이즈가 생기는 문제는 가우시안 블러를 활용해서 감춘다. 그리고 실제로 표시할 큰 이미지의 로딩이 완료되면 저해상도 버전을 뒤로 감추고 페이드 효과와 함께 실제 이미지를 표시한다. 이 기번은 콘텐츠보다 성능을 우선시해 빠른 로딩을 보장할 뿐 아니라, 이미지 영역을 미리 확보래서 고해상도 버전 로딩이 완료되기 전에 페이지 레이아웃이 깨지는 것을 방지한다.

 
3) 진행상태 표시자(진행표시줄)
정확도와 상관없이 진행 표시줄을 보는 것만으로도 사용자는 대기 시간을 더 관대하게 받아들인다고 한다. 

 
👉🏻 요청한 작업이 처리되고 있다는 사실을 분명히 알 수 있다.
👉🏻 사용자가 기다리는 동안 볼거리를 제공한다.
👉🏻 실제 대기 프로세스가 아닌 진행표시줄 애니메이션에 관심이 집중되어 기다린다는 느낌을 줄여준다.
👉🏻 낙관적 UI도 체감 성능을 개선하는 영리한 기법이다.
 

---

 

[반응이 너무 빠를 때]

 
반응 시간에 관한 문제는 대부분 반응이 너무 느릴 때 발생한다. 반응이 지나치게 빠른 상황에도 대비할 필요가 있다.

 

• 변화가 너무 빨리 일어나면 눈치채지 못할 수 있다.
• 반응이 너무 빠르면, 오히려 신뢰도가 떨어질 수도 있다.
   

---

 

[정리]

 
성능은 개발팀만 고민하면 되는 기술적인 문제가 아니라 본질적인 디자인 요소다. 디자이너라면 자신이 디자인한 제품이나 서비스의 사용자가 작업을 최대한 빠르고 효율적으로 완수하도록 도와야 한다. 이러한 목표를 이루려면 사용자에게 적절한 피드백을 제공하고, 체감 성능을 높이고, 진행표시줄을 사용해 기다린다는 느낌을 줄여주는 게 중요하다.