이 포스트는 UX/UI의 10가지 심리학 법칙 (존 야블론스키 저)에서 소개된 10가지 법칙을 소개하는 페이지입니다 .

각각의 내용에 보다 자세한 내용은 책을 참고 바라며 저자의 웹 사이트 https://lawsofux.com 에서 해당 법칙들에 대한 소개글을 볼 수 있습니다.

---

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

핵심

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

개요

• 뛰어난 사용자 경험을 만드는 필수 요소 중 하나는 성능이다. 속도는 기술적인 문제일 뿐 아니라 사용자 경험의 핵심이 되는 디자인 요소이기도 하다.
  • 제품이나 서비스를 처음 로딩하는 데 걸리는 시간, 인터랙션에 반응해 피드백을 제공한 속도, 다음 페이지를 로딩하는 데 걸린 시간 등 시스템 반응 속도는 전체 사용자 경험을 좌우하는 열쇠다.
• 웹사이트와 앱의 성능에 영향을 미치는 요소 중 가장 중요한 건 전체 페이지의 용량이다.
  • 평균 웹 페이지 용량은 해마다 증가하고 있는데 이로 인해 대기 시간이 길어지면 답답함을 느끼다 못해 작업까지 포기하는 사용자가 늘어난다.
• 반응이 즉각적으로 느끼려면 0.1초 이내여야 하며 지연이 1초 이상으로 늘어나면 사용자는 집중하기가 어려워지고 작업 수행에 필요한 정보를 놓치기 시작하여 생산성은 필연적으로 감소한다.

기원

• PC가 등장한 초창기에는 PC 작업 수행 반응 시간의 임계값이 2초로 여겨졌다.
  • 이를 사용자가 그 다음 작업에 대해 생각할 시간으로 쓸 수 있다고 간주되어 표준으로 받아들여 졌다.
• 그러나 1982년 IBM 직원 2명은 반응 시간이 0.4초 이하일 때 “생산성은 반응 시간 감소의 정비례 이상으로 증가한다”고 명시하며 표준에 이의를 제기했다.
  • 컴퓨터의 반응 시간이 생산성에 불균형한 영향을 미친다는 도허티(Doherty)의 발견을 바탕으로 도허티 임계(Doherthy threshhold)라고 알려진 새로운 표준이 탄생했다.

사례

• 처리 시간이 도허티 임계가 규정한 시간보다 많이 걸려도 딱히 개선할 방법이 없을 때도 있다.
  • 이럴 때는 필요한 프로세싱이 수행되는 동안 사용자에게 처리 시간에 관한 피드백을 주면 좋다.
• 페이스북 같은 플래폼에서 흔히 보이는 사례로 콘테츠를 로딩하는 동안 표시하는 뼈대 화면이 있다.
  • 뼈대 화면은 콘텐츠가 로딩되는 동안 콘텐츠 영역에 임시로 자리표시자 블록을 표시하는 것을 가리킨다.
  • 이를 사용하면 더 빨리 로딩되는 것처럼 보여 콘텐츠 로딩 속도가 느려도 기다린 다는 느낌이 덜해서 속도와 반응성이 실제보다 더 낫다고 인지한다.
• 로딩 시간을 최적화하는 ‘블러 업(blur up)‘이라는 기법도 있다. 이미지가 웹 등의 로딩 시간을 증가시키는 주범이라는 점에 착안해 이미지에 집중한다.
  • 실제 큰 이미지를 표시할 공간에 아주 작은 크기로 이미지를 로딩한 후 크게 확대해서 표시하는 기법이다.
  • 저해상도 이미지가 커지면서 픽셀이 깨지고 노이즈가 생기는 것은 블러를 활용해 감춘다.
  • 그 후 페이드 효과와 함께 저해상도 이미지를 감추고 실제 이미지를 표시한다.
• 로딩이나 프로세싱이 진행되는 동안 애니메이션으로 사용자의 시선을 끌기도 한다.
  • 진행표시줄(progress bar)을 사용함으로써 사용자는 대기 시간을 더 관대하게 받아들인다.
• 사용자가 눈앞의 작업에 집중을 유지할 수 있는 한계는 일반적으로 10초이며 이 시간을 넘어가면 사람들은 딴짓을 하고 싶어 한다.
  • 이 때 진행표시줄을 사용하되, 완료까지 예상 대기 시간과 현재 수행 중인 작업의 설명을 추가로 제공하면 좋다. 이를 통해 사용자는 자유시간이 얼마인지를 알 수 있다.

심화 학습

반응이 너무 빠를 때

• 대부분의 반응 시간에 관한 문제는 대부분 반응이 너무 느릴 때 발생하지만, 반응이 지나치게 빠른 상황에도 대비할 필요가 있다.
• 변화가 너무 빨리 일어나면 아예 눈치조차 채지 못할수도 있다. 특히 자동으로 일어난 변화라면 이런 문제를 일으킬 수 있다.
• 반응이 너무 빠르면 정신적으로 처리할 시간이 충분히 확보되지 않아 무슨 일이 일어난 건지 사용자가 이해하기 어려울 수도 있다.
• 또한 반응이 너무 빠르면 오히려 신뢰도가 떨어질 수도 있다. 실제 작업이 훨씬 빨리 완료되더라도 의도적으로 작업 완료를 늦게 알리는 것이 체감 가치를 높이고 신뢰를 형성하는 데 도움이 되기도 한다.
  • 페이스북 보안 점검 프로세스의 경우 스캔 중인 내용을 사용자에게 알려주고 일부러 점검 작업 시간을 늘려 스캔이 철저하게 이루어진다는 신뢰를 심어준다.

정리

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