도허티 임계와 UX 디자인
사내 스터디 - UX/UI의 10가지 심리학 법칙
2월 마지막 주 금요일, 사내 스터디 시간에 UX/UI의 10가지 심리학 법칙을 읽고 정리하여 발표하였습니다. 책은 다소 가볍지만 제게는 생각해볼거리가 많은 무거운 책이었어요. 꼭꼭 씹어 소화하고 싶은 내용이 많았기 때문에, 스터디로 끝내는 것이 아니라 글로 잘 정리하고 싶어졌습니다.
우선 이번 글에서는 책의 10장 도허티 임계(Doherty threshold)의 개념과 이와 관련하여 사용자의 체감 성능을 높이는 방법에 대해 정리하였습니다.
도허티 임계 (Doherty threshold)
"사용자의 주의가 분산되는 것을 막고 생산성을 높이려면 시스템의 반응은 0.4초 이내에 이루어져야 한다."
1982년 IBM 직원 2명(Walter J. Doherty, Ahrvin J. Thadani)이 IBM 기술 보고서를 발표합니다. The Economic Value of Rapid Response Time (빠른 반응 시간의 경제적 가치)
PC가 작업을 수행하는 반응 시간이 0.4초 이하일 때 생산성은 반응 시간 감소의 정비례 이상으로 증가한다.
컴퓨터와 사용자가 서로 기다리지 않아도 되는 속도로 인터렉션 할 때 생산성은 급격히 높아지고, 컴퓨터로 하는 작업에 드는 비용도 크게 줄어든다.
직원의 업무 만족도 향상, 작업 결과의 품질도 개선된다.
당시 PC 초창기에는 PC가 작업을 수행하는 반응 시간의 임계값의 표준을 2초로 여겨왔었다고 합니다. 당시에는 이 시간 동안 사용자가 그다음 작업에 대해 생각할 시간으로 쓸 수 있다고 간주되었기 때문이었다고 하는데요.(..?) 이 연구로 인해 오히려 컴퓨터 반응 시간이 생산성에 안 좋은 영향을 미친다는 도허티의 발견이 있었고, 이것을 기준으로 도허티 임계(Doherty threshold)이라는 새로운 표준이 탄생했다고 합니다.
도허티 임계와 UX 디자인
그렇다면 도허티 임계와 사용자 경험을 디자인하는 것에는 어떤 관계가 있을까요.
도허티 임계값인 0.4초는 상황과 사람에 따라 절대적인 수치는 아닐 수 있다고 생각해요. 하지만 제품의 응답이 1초 이상으로 늘어나면 사용자는 집중이 어려워지고 작업 수행에 필요한 정보를 놓칠 수 있다고 합니다. 그 결과 작업을 이어가기에 인지 부하가 커져 사용자 경험은 전체적으로 나빠지고...
(작업 반응 시간이 길어짐에 따라 제품을 사용하려는 사람들이 떠난다 / 반응 시간을 빠르게 개선함으로써 이탈률이 감소하고 수익이 높아졌다. 는 내용은 쉽게 찾아볼 수 있었습니다. How One Second Could Cost Amazon $1.6 Billion In Sales / How Does Page Load Time Affect Your Site Revenue?)
더 나은 제품 경험을 위해 제품의 반응 속도를 개선하는 것이 필요하지만, 기술적으로 제품의 반응 속도를 빠르게 하는 데에는 한계가 있을 수 있습니다. 또 사용자가 어떤 환경에서 제품을 사용하는지에 따라 반응시간은 크게 달라질 수 있기 때문에 기술적인 부분으로만 해결하기는 어렵습니다.
오히려 제품의 반응 속도는 사용자 경험에 크게 영향을 미치기 때문에 이 부분은 사용자 경험의 핵심이 되는 디자인 영역이라고 봐야 할 것입니다.
그럼 디자이너는 어떻게 제품의 반응 속도를 줄여 사용자 경험을 개선할 수 있을까요?
체감 성능 높이기
디자이너는 디자인 요소를 사용하여 "체감 성능"을 높여서 대기시간에 관대해지도록 할 수 있습니다.
체감 성능을 높인다는 것은 실제의 제품 반응 속도는 그대로이지만, 사용자가 느끼는 속도는 더 빠르다고, 또는 덜 지루하다고 느낄 수 있도록 만드는 것입니다.
(고객을 속이는 것은 아니고..) 사용자가 제품에게 요청한 작업이 처리되고 있다는 사실을 분명히 알려줘서 신뢰도를 높이고, 사용자가 기다리는 동안 볼거리 제공하는 것, 그리고 제품이 지금 어떤 상황인지를 알려줌으로써 사용자가 느끼는 대기 시간의 모호함과 지루함을 덜 느낄 수 있도록 하는 것입니다.
이런 목적으로 쓸 수 있는 UI 패턴은 여러 가지가 있는데 여기서는 아래의 내용을 소개합니다.
스켈레톤 스크린
이미지 로딩 시 블러 업
(정확하진 않더라도) 작업 진행 상황에 대한 Progress bar /Progress indicator
Optimistic UI
1. 정보의 스켈레톤 스크린 처리
스켈레톤(뼈대) UI: 제품에서 데이터를 불러오거나 변경하는 과정에서 발생하는 대기 시간 동안 실제 데이터로 채워질 영역에 임시로 보여지는 블록으로 화면을 간략하게 표현하는 것. 와이어프레임 형태와 유사합니다.
2. 이미지 로딩 시 블러 업 처리
이미지를 점진적으로 로드하여 보여주는 것. 화질은 낮고 작은 이미지를 확대하여 보여줍니다. 이때 픽셀이 깨지는 것을 블러 처리하여 먼저 보여주고, 로딩이 완료되면 고해상도의 원본 이미지를 보여주는 방식입니다.
3. 작업 진행 상황 Progress bar /Progress indicator
간단한 로고 애니메이션과 Progress bar는 진행상황을 알 수 있어서 불확실성을 줄여주고, 체감 대기 시간을 줄여줄 수 있습니다.
4. Optimistic UI
사용자의 대기 시간을 압도적으로 줄여주기 위하여 제품 반응을 기다리는 것이 아닌, 제품의 성공적인 반응을 먼저 보여주는 것. 실제 제품의 정보 처리는 백그라운드에서 진행됩니다.
제품이 사용자가 요청한 행동이 성공적으로 처리될 것이라는 것을 가정하고 즉각적인 피드백을 제공하는 것이기 때문에 사용자의 만족도는 높아질 수 있습니다.
옵티스틱 UI는 실패할 경우에 대한 대응이 필요합니다. 사용자는 이미 "성공"의 반응을 봤지만, "앗 사실은 실패했어" 라고 알려줘야 하는 상황이 생길 수 있흡니다.
페이스북의 like 버튼의 반응이 옵티미스틱 UI로 구현 되어 있습니다.
로딩이 실패할 경우에는 미묘하게 원래 상태로 돌려놓는 방식으로 구현되어 있습니다. 성공할 것이라는 가정하에 like 버튼이 눌리고, 숫자는 올라가지만, 인터넷 연결이 되어 있지 않아 다시 원래 상태로 되돌아오는 모습을 볼 수 있습니다.
옵티미스틱 UI는 얼마 전 사내에서 사용할 목적으로 "로딩 상황 처리"에 대한 디자인 가이드를 작성하며 고민하던 개념이었는데, 최근 이 책과 옵티미스틱 UI에 대한 글을 찾아 읽으며 정확한 명칭과 작동방식에 대해 정리할 수 있었습니다.
마치며
도허티 임계와 제품의 경험은 밀접하게 연결되어 있습니다만, 디자이너는 제품이 언제 반응 속도가 저하되는지, 어디서 고객이 느끼는 체감 성능을 높여야 하는지 알기 어려울 수 있습니다. 이런 부분에서는 제품을 함께 만드는 엔지니어와의 밀접한 협업이 필요합니다.
우리의 고객은 우리가 생각하는 것보다 다양한 환경에서 제품을 사용하게 됩니다. 그런 상황에서 고객이 나쁜 경험을 겪지 않도록, 되도록이면 명확하고 즐거운 경험을 하도록 제품을 설계해야 한다는 것을 다시 한번 느꼈습니다.
개인적으로 도허티 임계와 여러 패턴에 대한 스터디를 통해 이제까지 머릿속에 흩어져있는 여러 개념이 잘 정리되는 시간을 경험했습니다. 특히 최근에 로딩 상황 처리를 어떻게 할 것인가에 대한 가이드를 작성하였는데, 이 개념을 학습함으로써 좀 더 탄탄한 가이드를 작성할 수 있을 것이라는 자신감이 생겼습니다.
존 야블론스키는 사용자 경험 디자인과 프런트엔드 웹 개발의 교차 지점에 대한 강한 열정이 있다고 합니다. 프런트엔드 웹 개발에 대해 깊이 아는 것은 어려울 수 있지만, 어느 정도 이해할 수 있다면 디자이너로서 제품을 분석하고 만드는 관점 모두가 확장될 것입니다.
참고 자료
https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=250936100
https://jlelliotton.blogspot.com/p/the-economic-value-of-rapid-response.html
https://uxplanet.org/optimistic-1000-34d9eefe4c05#.i3zxqxrim
