태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.


'UI법칙'에 해당되는 글 9건

  1. 2012.12.20 Keystroke-level model (KLM)이란? by 이 재용
  2. 2012.12.17 Model Human Processor (MHP,인간 정보 처리 모형)란? by 이 재용
  3. 2012.12.12 밀러의 매직 넘버 7(The Magical Number Seven)이란? (2) by 이 재용
  4. 2012.12.10 선택의 역설- 쨈 얘기는 이제 그만 (1) by 이 재용
  5. 2012.11.27 힉의 법칙(힉스 로,Hick's Law)이란? (7) by 이 재용
  6. 2012.09.20 피츠를 알려주는 퀴즈 (A Quiz Designed to Give You Fitts) (3) by C.yoon
  7. 2012.09.19 피츠의 법칙 Fitts' Law (3) by 이 재용
  8. 2012.03.11 [독후감]사람에 대한 100가지 사실 by 이 재용
  9. 2010.04.13 윈도우 7 fitts's law 적용 실패 사례 by 無異
2012.12.20 07:30

Keystroke-level model (KLM)이란?

Keystroke-level Model (KLM 혹은 KLM-GOMS, 타자 수준 모형)이란 Human Computer Interaction에서 키보드와 마우스를 조작하는 단위 요소들의 소요 시간을 미리 측정해 두었다가, 전체 시간을 측정해야하는 동작이 있을 때, 이미 알려진 값들을 합산하여 계산할 수 있게 만든 접근법이다. 예를 들어 키보드 하나를 누르는 데 걸리는 시간은 200ms, 마우스 버튼을 누르는데 걸리는 시간은 100 ms, 키보드에서 마우스로 이동하는데 걸리는 시간은 400 ms 등으로 평균적인 인간의 소요 시간을 측정해 둔 테이블을 준비해 둔 뒤, "apple 타이핑 후 마우스 클릭하는데 걸리는 시간"은 5*200+400+100=1.5초 라는 식으로 계산하는 방법을 말한다(설명을 위해 간단히 말한 것이며 정식 계산은 아래 참조)

이 방법은 Card 등에 의해 개발된 GOMS라는 방법에 기초하여 David Kieras가 1993년에 발표한 것으로 KLM-GOMS라고도 불린다. 다른 GOMS의 방법들에 비해 이해가 쉽고 적용하기가 간단하여 많이 사용되는 방법이다.

그가 제시한 계산에 사용되는 요소 행동 몇 가지만 보면,

K: 키보드의 키를 눌렀다가 떼는 행동. 상황에 따라 다른 값을 갖는데, 익숙한 단어 내의 키는 0.2초(200ms) 정도, 랜덤한 키는 0.5초(500ms) 정도로 볼 수 있다(보통의 타자 속도를 가진 사람의 경우. 자세한 건 영문 위키 참조)
P: 마우스를 특정 위치에 가져가는 것 1.10초
B: 마우스 버튼을 누르는 것, 혹은 떼는 것 0.10초
H: 마우스에서 키보드로, 혹은 키보드에서 마우스로 손(Hand)을 이동 0.4초
M: 정신적인 준비(Mental preparation) 1.20 초
W(t): 시스템이 반응할 때까지 대기하는 시간

등이다.

예를 들어 위에서 간단하게 설명한 것을 정식으로 풀어보자면,

"apple 타이핑 후 마우스 클릭하는데 걸리는 시간"을 계산하라

-우선 모든 행동의 시작에는 정신적인 준비 시간 M이 필요하다.
-그 다음 model 타이핑을 해야하는데, 이 경우 랜덤한 키가 아니고, 익숙한 단어의 일련의 타자 행위이므로 (KLM에서는 -숙련 사용자를 가정한다) K1 = 200 ms 가 각 글자당 필요하다.
-이 때 시스템은 매우 빠르게 반응하여, 사용자가 입력 후 그 입력을 기다릴 필요(즉 W)는 없다고 가정한다.
-하지만 마우스를 클릭해야한다는 사실은 "생각"해야 한다. M
-그 다음은 손을 키보드에서 마우스로 옮겨야 하므로 H가 필요하고,
-그 다음은 마우스를 이동할 필요가 없다고 가정하고(만약 필요하다면 간단하게 P=1.1초를 사용하거나 정식으로 Fitt's Law 사용하여 계산),
-마지막으로 마우스를 클릭하는 시간까지만(릴리즈 시간은 무시하고) 계산한다면 B가 필요하다.

M+K1+K1+K1+K1+K1+M+H+B = 1.2 + 5 * 0.2 + 1.2 + 0.4 + 0.1 = 3.9 초

물론 구체적인 태스크에 따라서, 타이핑 후 마우스 클릭이 거의 '자동'으로 이루어진다면, 두 번째 M은 필요하지 않을 수도 있다.

이 방법을 사용하면, 새로 설계한 인터페이스에서 특정 태스크를 수행할 때 얼마나 시간이 걸릴지 미리 예측할 수도 있고, 두 개의 서로 다른 UI가 있을 때 어떤 것이 더 빨리 수행할 수 있을지를 평가할 수도 있다.

물론, UI 에서 몇 ms 줄이는 것이 더 이상 중요하지 않은 경우가 대부분이고, 빨리 효율적이게 하기 보다는 더 좋은 경험(UX)을 갖게 하는 것이 중요하기는 하지만, 콜센터처럼 숙련된 수만 명의 사람들이 반복하여 하루 종일 사용하는 인터페이스를 만든다면 UI에서 몇 초를 줄였을 떄 전체적으로 엄청난 경비 절감으로 이어질 수도 있기 때문에 UI를 하는 사람들이 소홀히 할 수는 없는 내용이다.

참고: Wikipedia: Keystroke-level Model 
참고: 심리학 사전: 타자 수준 모형

[참고##UI법칙##]

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 0
Ad Test...
2012.12.17 07:30

Model Human Processor (MHP,인간 정보 처리 모형)란?

Model Human Processor(인간 정보처리 모형 human information processor model,이하 MHP)란, 사람이 어떤 자극에 반응하여 근육을 움직이는데까지 일련의 과정을 분할하여 어느 정도의 시간이 걸리는지 측정하여 둔 뒤, 어떤 태스크를 할 때 얼마나 시간이 걸릴지를 쉽게 계산해 볼 수 있도록 만든 인지적 모형이다. 1983년  Card, S.K., Moran T.P., & Newell, A.등에 의해 제안되었다.


Wikipedia : Human processor model

사용성 평가 방법에는 사용자를 직접 데리고 하는 직접법과 사용자 없이 하는 간접법이 있는데, 간접법은 다시 사용자를 잘 아는 전문가를 활용한 전문가법과, 전문가 없이 미리 실험된 데이터만으로 유추해보는 모형법으로 나누어 볼 수 있다. 이러한 모형법으로는 GOMS, KLM 등이 잘 알려져있다.

MHP는 세 개의 하부 시스템으로 이루어져 있는데 지각(Perceptual Subsystem), 인지(Cognitive Subsystem), 운동(Motor Subsystem) 시스템으로 나누어 볼 수 있다. 어떤 자극을 감각 기관을 이용하여 지각하고, 머리속에서 판단(인지)한 다음 손의 근육을 움직여 반응하는 순서를 상정한 것이다. 각 시스템별 하부 모듈의 처리 시간을 측정 평균하여, 보통 사람의 경우, 빠른 사람의 경우, 느린 사람의 경우를 표로 정리해 제공한다.

예를 들어 지각 시스템도 정보를 처리하는데 시간이 걸리는데, 시각 지각 시스템의 경우 하나의 신호를 처리하고, 또 다음 신호를 처리하는 주기가 대략 100 ms 정도 걸린다고 한다. 이것은 보통의 인간(middle man)의 경우이고, 아주 빠른 사람은 50 ms마다 이미지 하나를 처리하고 다음 이미지로 넘어갈 수 있으며 느린 사람은 200 ms 정도 주기로 이미지를 처리할 수 있다고 한다.

따라서 우리가 애니메이션 영화를 만든다고 했을 때, 1초에 10컷 (즉 1컷에 100ms)을 보여준다면 대부분의 사람들은 자연스럽게 움직임을 느낄 것이나, 신호 처리가 빠른 사람들은 이상하다고 느낄 것이다. 빠른 사람을 기준으로 한다면 최소 1초에 20컷 (즉 1컷에 50ms)은 되어야 하며, 좀 더 안전하게는 초당 24프레임 혹은 30 프레임을 사용하는 것이 적당하다는 계산이 나온다.

이렇듯 각 모듈에서 걸리는 시간은 보통, 빠른 사람, 느린 사람으로 구성되어 있으며, 원하는 태스크를 잘게 잘 나눈 다음 각 태스크에서 소요되는 시간을 보통, 빠른 사람, 느린 사람으로 나누어 합산하면 전체 태스크를 수행할 때, 보통, 빠른 사람, 느린 사람이 각각 어느 정도 시간이 걸릴지 예측해 볼 수 있다. 

[참고##UI법칙##]

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 0
Ad Test...
2012.12.12 07:30

밀러의 매직 넘버 7(The Magical Number Seven)이란?

밀러의 매직 넘버 7 (혹은 마법의 숫자 7)이란, 일반적으로 인간이 단기로 기억할 수 있는 아이템의 개수는 7개 전후(5~9)라는 의미로, 아마 UI / UX 분야에서도 가장 많이 인용되지만 가장 엉터리로 응용되고 있는 법칙일 것이다.

영문 Wikipedia: The Magical Number Seven, Plus or Minus Two를 바탕으로 잠깐 설명해 보면,

밀러의 논문
프린스턴 대학교 교수인 George A. Miller는 1956년에 "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information"라는 논문을 발표하였다. 밀러는 1차원 절대판단(absolute judgment) 실험에서 높이만 다른 10가지 음을 들려 주었을 때, 대부분의 사람들이 5-6개까지는 잘 대응하는데 그 이후로 급격히 떨어지는 것으로 보아 이 자극에 대한 저장 용량은 2-3비트로 이루어졌다고 유추할 수 있으며, 대략 4-8가지를 처리할 수 있다고 보았다. 또 다른 실험에서는 기억 범위(memory span)를 측정했는데, 기억 범위란, 일련의 정보를 알려주고, 즉시 되기억해 낼 수 있는 최대 개수를 말하는데, 대부분의 젊은이들이 대개 7개 정도를 기억하는 것으로 파악했다. 특히 밀러는 여기서 기억하는 단위가 단순한 개별 아이템의 개수가 아닌 의미로 묶어지는 하나의 덩어리(chunks)임을 알아냈다. 예를 들어 모르는 언어의 단어는 글자 하나하나가 청크이지만, 잘 아는 언어의 단어는 단어 하나가 청크여서, 모르는 언어는 한 단어를 기억하기도 어렵지만, 잘 아는 단어는 7개의 단어도 기억할 수 있다는 의미가 된다.


반론
그런데 밀러는 이 두 가지에서 우연적이게도 비슷하게 7 정도로 일치하니까 순전히 비유적인 의미로 마술 같은(magical)이라고 표현했는데, 그 이후로 많은 논문에서 이를 그대로 인용하게 되어 버렸다. 애당초 밀러도 마술같은 숫자가 있다고 생각하지 않은 것이다.

그 이후 많은 실험에서 이렇게 절대적인 숫자의 기억 용량이란 없는 것으로 밝혀졌다. 기억하려는 종류에 따라, 또는 각 개별 청크에 따라서도 개수는 변화했다. 어떤 사람들은 이 용량은 청크의 개수 보다는, 발음하여 읽었을 때의 길이(대략 2초 분량)로 정해진다고 주장했다. 

또 수잔 웨인쉔크(Susan M. Weinschenk)의 사람에 대한 100가지 사실에 따르면, 밀러의 연구가 잘못되었다고 한다(Alan Baddeley, 1994). 새로운 연구(Baddeley 1996, Nelson Cowan 2001)에 따르면 7이 아니라 4라고 한다. 미주리대 심리학과 교수인 Cowan에 따르면 젊은이의 경우 Working Memory는 대개 3-5의 용량 한계를 갖는다는 것이다. 

결론
필자가 마법의 숫자 7을 처음 들은 것이 1993년이었는데, 그 때만해도 그것이 무슨 절대적인 법칙인양, 10개가 넘는 메뉴를 보면 다들 비웃었다. 포털이나 신문사 홈페이지에는 쉽게 50개 이상의 링크가 실리게 되는데, 이것이 법칙을 어긴 것이라고 가르치는 교수님들도 많았다. (물론 필자도 한동안 이것이 무슨 의미가 있는 숫자인양 가르쳤다) 이제부터 4라고 가르쳐야 하나? 아니면 2초라고 가르쳐야 하나?

하지만 여러 실험에 의해 보듯이, 그리고 우리의 상식이 말하듯이, 모든 정보의 종류를 묻지도 따지지도 않고, 절대적으로 기억하고 처리할 수 있는 정보의 용량이라는 것은 존재하지 않는다. 더 이상 7이라는 숫자를 우기지 말자. 오히려 구체적으로 콘텐트에 따라 달라진다. 

사람이 단기로 기억하고 처리할 수 있는 개수는 매우 적다-라는 사실은 우리 모두 알고 있다. 상식이다. 그러니 우리는 그것을 최대한 고려하여 메뉴의 개수, 링크의 개수나 선택지의 개수를 정해야 한다. 최대한 개수를 줄이고, 가능하면 묶음을 만들고, 쉽게 판단할 수 있는 도구를 제공해야 한다. 얼마나 기억할 수 있느냐는 것은, 그 대상이 무엇이고, 우리의 사용자(퍼소나)가 어떤 상황에 어느 정도의 숙련도를 가진 사람이냐에 따라 매우 달라진다.

마법의 숫자 7이란 존재하지 않는다.

참고
The Magical Mystery Four: How is Working Memory Capacity Limited, and Why? by Cowan 
Four is the ‘magic’ number for our mind coping with information
[독후감]사람에 대한 100가지 사실

이 글은 Tech It!에도 실렸습니다.

[참고##UI법칙##]

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 2
Ad Test...
2012.12.10 07:30

선택의 역설- 쨈 얘기는 이제 그만

선택에 관하여 가장 널리 인용되는 연구 중 하나는, 스탠포드 대학원생이었던 Iyengar의 쨈 판매량에 관한 이야기일 것이다. 짧게 요약하면, 쨈 시식대에서 24가지 종류의 시식을 했을 때는 사람들이 더 많이 몰려들었지만 3%만 구매했고, 6가지 종류를 맛보게 했을 때는 30%가 구매했다는 내용이다(참고)

이에 따라 많은 선택을 제공하면 더 많이 선택할거라는 일반적인 사람들의 믿음과 반대로, 선택지를 많이 제공할수록 사람들은 더 적게 선택한다고 하여 이를 '선택의 역설(Paradox of Choice)'이라고 불렀다. 1990년대 중반에 실행된 이 연구는 이후 많은 사람들에게 다시 '상식'이 되었다.

선택의 역설
이러한 주장으로 매우 유명한 책이 2004년 Barry Schwartz 교수의 선택의 심리학(초판 번역서 제목은 선택의 역설, The Paradox of Choice: Why More is Less)이다. 사회 행동학 교수인 그는, 선택의 가지수가 많을수록 사람들은 불행해 질 수 있다고 주장한다. 물론 선택이 늘어나면 행복해지는 부분이 있지만 언제나, 모두에게 그런 것은 아니라는 점이다.

특히 그는 TED 연설 The Paradox of Choice에서 이렇게 말했다. 은퇴 자금 투자 펀드 연구에서, 펀드를 더 많이 추천하면 할 수록 가입하는 확률이 떨어졌다. 사람들에게 너무 중요하니까 좀 더 고민해 보려고 미루다가 결국 가입 못 하게 되는데, 추천한 펀드가 많으면 많을수록 고민을 더 해야하기 때문이다.
또 종류가 너무 많으면 어느 하나를 고른 뒤에도 자기가 안 고른 어떤 것 중에서 자기에게 더 잘 맞는 것이 있지 않을까 하는 생각 때문에 만족도가 떨어진다.  결국 선택지가 많아질수록, 선택하기는 더 어렵고, 선택한다고 해도 만족하기 힘들다.

이렇듯 선택이 많아지면 구매도 떨어지고, 만족도도 떨어지는데, 왜 우리는 여전히 많은 선택 가운데 둘러쌓여 있는 것일까? 이상하지 않나? 왜 안경점의 수많은 안경테를 당장 없애지 않는걸까? 왜 스타벅스는 수만가지 음료가 가능하다고 선전할까? 네이버는 왜 첫 화면에 수백 개의 링크를 걸어 두고 줄이지 않는 걸까?

선택의 역설의 역설
그래서 어떤 사람들은 선택의 역설의 역설을 이야기한다.
Financial Times에 소개된 Benjamin Scheibehenne의 실험에 의하면, 쨈 실험을 따라한 여러 실험을 했지만 선택지의 많음이 판매를 방해하는 어떤 증거도 발견되지 않았다는 것이다. 때론 선택의 개수가 판매에 영향을 미치는 상황이 있는듯 했지만, 그것이 정확히 무엇인지는 알 수가 없었다고 한다.

애당초 쨈 실험도 믿지 않았지만, Scheibehenne의 실험도 얼마나 믿어야할지는 모르겠다. 그러나 분명한 건, 선택지가 많으면 피곤하고 시간이 오래 걸리는 건 상식이라는 점이다. 그렇다고 정말 "일괄적으로" 구매가 떨어진다거나, "일괄적으로" 만족도가 떨어진다는 법칙 따위는 없을 것 같다. 선택지의 숫자와 선택의 확률은, 그냥 단순하게 말해서 둘 사이 관계는 너무 복잡해서 한 마디로 말할 수 없을 듯 하다. 

UX에서 선택
UX에서도 마찬가지라고 생각한다. 어떤 경우에도 통하는 일반적인 법칙을 만들고 신봉하기 보다는, 자신이 설계하려는 UI에서 최대한 선택의 개수를 줄이려 하거나, 적어도 효율적인 UI가 되는데 가장 좋은 선택지의 개수를 찾으려는 노력을 해야하는 것이 당연해 보인다. 

더 나아가, 단지 효율을 생각하는 UI가 아니라 만족스런 경험을 위한 UX라면, 오히려 선택지를 늘려 풍부한 옵션(콘텐트)가운데 선택했음이 만족으로 남는 상황도 고려해야 한다. 구체적인 사용자(퍼소나)가 구체적인 데이터를 다루는 상황을 생각하면 최적의 개수를 유추할 수 있다. 

더 이상 쨈 얘기는 그만하자.

(이미지 출처:http://www.sitepoint.com/offline-design-inspiration-part-3-food-packaging/)

[참고: PWC 김이식 상무의 구매 결정 단계와 선택지 개수의 역할]
(편집자)정보 탐색 단계에선 더 많은 선택지가 유리하고, 대안 평가 단계에선 더 적은 선택지가 유리하다는 김이식 상무의 권고안은 직접적으로는 온라인 쇼핑몰에서 적용할 수 있지만, '기능이 많아야' 팔리고, '기능이 적어야' 쓰기 쉬운 정보 제품 UX 설계에도 매우 중요한 역할을 한다

상품을 파는 입장에서는 2가지 중요한 포인트가 있다. 고객을 우리에게 오게 만드는 것이 첫번째고, 온 고객에게 파는 것이 두번째다. (아주 중요해서 2가지 지표를 꼭 관리해야 한다.)

정보의 다양한 수집 단계
대개의 경우 고객이 우리에게 올 때는 다양한 선택을 할 수 있는 곳을 고른다. 대부분의 경우 고객은 아직 어떤 것을 살 것인가를 결정하지 않았기 때문이다.(예외도 많다. 면세점 화장품이 그렇다) 그래서 다양한 정보를 획득할 수 있는 곳을 선택한다. 매장을 가지고 있는 판매 형태의 경우 이 내점 순간이 가장 중요하고 이 때 대부분의 매출이 결정 된다. 그래서 많은 회사들이 상품 구성의 다양함을 강조한다. 마지막에 사느냐 마느냐보다 우선 우리 가게로 들어오는 것이 중요하기 때문이다.

결정단계
다양하게 살펴본 후 결정 단계에 진입하면 하나씩 줄여 나가야 한다. 그런데 이것이 종류가 많을수록 어렵다, 왜? 여러번 해야 하니까가 아니라 선택의 기준이 많기 때문이다. 상쾌한 결정을 하기 위해서는 어떤 것을 선택하는 명확한 기준이 필요한데 여러 개일 수록 기준이 여러 가지가 나오고, 기준이 많을수록 선택이 어렵다는 것이다, 즉 국어, 영어, 수학 등의 과목이 많고 총점은 모를때 누가 가장 공부를 잘한다고 할 수 있을까. 각 변수에 가중치를 둔 다항식을 머리로 만들고 풀어야 한다. 대부분 몇개 풀다가 어려워서 KO. 즉 선택 기준의 문제이다. 간혹 숫자가 많아도 결정이 쉬운 때가 있는데, 숫자는 많아도 기준은 하나인 경우가 그렇다.

권고안
그러면 매장에 선택을 많게 해야 하나 적게 해야 하나? 상황에 따라 다른 경우가 몇 개 있으나, 보편적인 답은 많게 해야 한다는 것이다. 고객 입장에서 A매장에서 B매장으로 이동하는 비용이 크니까, 다른 곳으로 쉽게 가지도 못 하지만 일단 다른 곳에 간 경우 돌아오기도 어렵기 때문에, 최초 내점에서 승부가 끝나기 때문이다.(인터넷 판매, 면세점 화장품 등은 그렇지 않다) 그러면 선택을 못하는 것은 어떻게 해결하나? 답은 선택을 도와주는 장치가 마련되어 있어야 한다는 것이다.

1. 가장 쉬운 답은 판매 직원이 선택을 정리해 주는 것이다. 이것은 이런 이유로 고객에게 안 맞고 이것은 이런 이유로 고객에게 안 맞고를 정해준다(판매사원이 권위가 있을 수록 좋다. 의사, 약사, 그 상품 전문가 등) 마지막 최종 선택은 기준만 남기고 빠지는 센스는 잊지말자. 그렇지 않으면 "당했다"라고 생각할테니.
2. 아니면 좀 물러나서 선택의 기준만 정해주는 것도 좋다.(소비자가 자신만의 기준을 가지고 있는 경우. 여성의류 등)
3. 아니면 선택을 쉽게 할 수 있도록 다른 장치를 둔다. 예를 들면 선택의 기준을 보여주는 더미 상품을 같이 배열한다. 아주 비싼 물건이나 아주 형편없는 물건이나 아무도 사지 않지만 비교를 할때 고객 자신의 어떤 선택을 해야 하는지를 기준과 범위를 알려줄 수 있다.


(이 글은 Tech It!에도 실렸습니다. )
 
[참고##UI법칙##] 

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 1
Ad Test...
2012.11.27 07:30

힉의 법칙(힉스 로,Hick's Law)이란?

힉의 법칙(Hick's Law)은, 사람이 무언가를 선택하는데 걸리는 시간은 선택하려는 가지수에 따라 결정된다는 법칙이다. 힉-하이먼 법칙(Hick-Hyman Law)이라고 부르기도 한다.

영문 위키피디아 - Hick's Law
한글 위키피디아 - 힉-하이먼 법칙

선택의 가지수가 많아지면 시간이 오래 걸리는 것은 누구나 알고 있었겠지... 그건 너무 당연하니까. 그런 걸 법칙이라고 만든 사람도 다 있나? 실은 내용이 좀 다르다. 대부분의 UI 법칙들을 사람들이 잘못 알고 있듯이, 이 법칙도 대부분의 사람들이 제대로 모르고 있다. 우선 어쩌다가 법칙이 되었는지부터 보자. 

1951년 영국 심리학자 힉은 10개의 램프가 있는 테이블에서 5초 간격으로 임의의 램프가 켜지게 하고 사용자가 그것을 누르는데 걸리는 시간을 측정했다. 이 때, 램프의 개수를 2개에서 10개까지 변화 시키면서 사람들이 선택하는데 걸리는 시간의 변화를 계산했더니, 램프의 개수가 많을수록 시간이 오래 걸렸다. 실험 내용을 보면 어느 정도 유추할 수 있겠지만 사람들이 흔히 잘못 알고 있는 부분을 짚어보겠다.


1. 시간이 확확 늘어나지는 않는다.
우선 이 법칙의 수식을 간단히 살펴보면,

T = b \log_{2}(n + 1)

선택지(n) 시간(T)
1 1.0
2 1.6
3 2.0
10 3.5
20 4.3
100 6.6
로 표현된다. 수학에 약한 분들은 오른쪽 그래프를 보면 된다. 처음에는 선택지가 늘어나면 시간이 늘어나는 것 같지만, n이 커지면 시간이 별로 늘어나지 않는다. 어라? 좀 더 정확히 설명하기 위하여 각 경우의 수를 계산해 보면(b=1로 가정), 표와 같이 3개일 때 2초라고 해서, 10개라고 6초 이상 걸리는 것이 아니라 조금 더 늘어날 뿐이고, 20개가 되어도 4.3초 정도 될 뿐이다. 

언듯 생각하기에 선택지가 늘어나면, 시간이 기하급수적으로 늘어나면 좋겠는데... 그래서 UX하는 사람들이 선택을 줄이는 것이 중요하다는 걸 더 강조할 수 있었으면 좋겠는데... 기하급수적으로 늘어나기는 커녕, 선형적으로도 늘어나지 않고... 그냥 로그적으로 늘어난다. 아주 쬐끔씩... 그러니까 이 법칙을 이용하면, "메뉴를 잘게 나누지 말고, 한 번에 많이 보여주어라"는 결론을 주는 것 같다. 어차피 100개에 6.6초지만, 1000개 가운데 고르는데는 9.9초밖에 걸리지 않으니까 말이다. 이상하지 않나?

왜 이런 결과가 나온 걸까?

2. 바이너리 검색에만 해당된다.
기본적으로 여기서 가정하는 것은 (실험에서 느껴졌겠지만) 매우 단순하고 단일한 선택을 인간이 하는데, 10개가 있다면 절반을 나누어 "왼쪽이냐? 오른쪽이냐?" 판단한 후, 오른쪽이라면 다시 5개 가운데, "왼쪽이냐? 오른쪽이냐?"라고 판단하는 식의 논리를 따르는 선택에만 해당이 된다. 그렇기 때문에 1000개나 되더라도, 우선 500개를 제거하고, 다음 250개를 제거하고, 이런 식으로 하기 때문에 많아져도 별로 시간이 늘어나지 않는 것이다. (이런 과정을 Binary Search 혹은 Binary Elimination이라 한다. 수식에서 n+1이 된 것은 하나라도 선택을 할 것이냐 말 것이냐의 선택이 있기 때문이다)

사실 그런데... UI 디자인에서, 이런 식의 선택은 거의 없다. 예를 들어 내가 무엇을 고를지를 알고 있고, 그 대상이 알파벳 순으로 정렬되어 있을 때(!) 적용이 된다. 이런 경우라면, A 보여주고, B 보여주고 이렇게 만들면 정말 짜증이 나고 오래 걸린다. 차라리, A부터 Z까지 한 번에 확 보여주면 더 빠르게 고를 수 있다.

그러나 대부분의 경우는, 화면이 작아서 A부터 Z까지 한 번에 보여줄 수도 없고, 또 그런 식으로 정렬할 수도 없는 아이템인 경우가 대부분이고, 또 그렇게 정렬할 수 있다고 해도, 무얼 선택할지 사용자가 미리 알고 있는 경우도 드물기 때문에 거의 적용이 될 수가 없는 검색 방법이다.

힉의 법칙이 적용되려면,
a. 사용자가 무엇을 선택할지 알고 있고
b. 선택지가 사용자에게 익숙하게 정해진 순서대로 정렬되어 있으며(예를 들면 숫자나 알파벳)
c. 모든 선택지를 한꺼번에 보여줄 수 있을 때(페이징이나 스크롤은 안 됨),

선택지를 그룹으로 나누어 보여주는 것 보다는, 한꺼번에 보여주는 것이 훨씬 빠르다!는 법칙을 적용할 수 있다.

3. 가장 중요한 건 선택의 가지수를 줄이는 방법이다. 
지금까지 본 바와 같이, Hick의 법칙 자체는 사실 써먹을 일이 드문 법칙이다. 따라서, 괜한 아는체 보다는, '상식'에 기대자. 선택의 수가 적으면 선택하는데 걸리는 시간도 짧다. 따라서 선택의 수를 줄이는데 최선을 다 해야한다.

그렇지 않으면 아래 한국어 위키피디아처럼, 이상한 내용을 주장하게 된다. (여기서 이상하다는 말은, 내용이 틀렸다는 것이 아니라 힉의 법칙과 상관이 없거나, 힉의 법칙과 반대된다는 뜻이다)

[필독] 힉스 법칙과 피츠 법칙의 실험, 연구 발전, 그리고 왜 피츠는 인기있는데 힉스는 인기없는가?
[참고] 힉스 법칙과 피츠 법칙을 이용한 선택 시간 계산 및 메뉴 깊이 최적화
[참고] 다중선택에서 결정 시간 최소화를 위한 적응형 최적 과정

[참고##UI법칙##]



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 7
Ad Test...
2012.09.20 08:23

피츠를 알려주는 퀴즈 (A Quiz Designed to Give You Fitts)

이 글은 Bruce Tognazzini가 1999년에 AskTog에 올린, 피츠를 알려주는 퀴즈(A Quiz Designed to Give You Fitts)를 번역한 것입니다. 10 수 년 전에 작성된 글이지만 여전히 얻는 부분이 크다고 생각합니다. 피엑스디에서 저자의 서면 허락을 받고 번역, 게시하였으며, 저자의 허락없이 복사하여 사용하는 것은 절대 안됩니다.


스스로 인터랙션 디자이너라고 생각하는가? 다음 질문에 빠르게 전문가적인 답변을 하지 못 한다면 인터랙션 디자이너가 아니다.

만약 인터랙션 디자이너는 아니지만, 주변에 아는 인터랙션 디자이너가 있거나, 인터랙션 디자이너를 채용할 계획이 있다면 이 질문을 던져보고 얼마나 잘 대답하는지 보라. 필자는 이 질문들을 인터뷰 과정에서 수년 동안 효과적으로 사용했다.

이 글은, 화면과 OS 등을 총괄하고 조정할 수 있는 권한을 가진 사람을 가정한 것이므로, 문제를 풀 때 스스로를 Microsoft 혹은 Apple의 수석 디자이너라고 생각하고 답하길 바란다.

Fitts라는 단어를 처음 접하는 사람들은 해설을 읽기 전에 문제를 먼저 풀어보라. 해설에서 관련된 원리를 빠짐없이 설명해 주겠지만, 처음에 최선을 다해 문제를 풀어봐야 과거에 본인이 어떤 추측을 해왔는지 보다 명확하게 알 수 있다. 그리고 그 다음에 그 추측을 정답과 비교해서 판단해 볼 수 있을 것이다. 그리고 성적이 나빠도 너무 우울해 할 필요는 없다. 컴퓨터 관련업계에 오랫동안 종사해 온 대다수의 사람들도 첫번째 시험 결과는 매우 저조한 편이다. 하지만 이들은 다시 풀어볼 때는 좋은 결과를 낸다. 그리고 많은 이들이 이 내용을 앞으로의 디자인 작업에 즉시 그리고 영구적으로 적용시킬 수 있다는 점을 알게 되기 때문에, 이 사이트(AskTog.com)에서 가장 가치있는 글이라고 생각하게 될 것이다.



퀴즈
먼저 대략적인 내용을 파악하기 위해 문제를 한 번 훑어보고 싶다면 그렇게 해도 좋다(답은 보지 말고!). 그 다음, 처음으로 돌아와서 하나씩 풀기 시작하라. 각 문제에 제대로 대답해야 한다. 이 퀴즈는 “아, 맞아, 나 이거 알아.” 하는 식으로 대충 훑어보고 넘어가기 위한 문제들이 아니다. 대답할 때는 분명하게 또박또박 해야 한다. (그렇지 않으면 틀린 것으로 간주한다.)

숨은 속임수 같은 것은 없지만 정답은 직관이나, 경험과는 반대될 수도 있고, 그래서 "당연하다고 여기는" 생각으로는 부족할 수 있다.



1. 마이크로소프트 툴바는 사용자들에게 각 도구명을 도구 하단에 레이블로 표시할 것인지에 대한 옵션을 제공한다. 레이블이 없을 때 보다는 있을 때 도구를 더 빨리 선택할 수 있는 이유를 한 가지 이상 말해보라. (사용자는 각 도구를 알고 있으며 필요한 도구를 찾는데 레이블은 필요하지 않다는 추정 하에 답해 보라)

2. 그래픽 프로그램에, 16x16픽셀 아이콘이 2x8(가로2줄, 세로 8줄로 16개)로 배열되어있는 도구 팔레트가 화면 왼쪽 가장자리에 배치 되어있다. 도구 팔레트의 위치를 변경하거나, 아이콘의 크기를 더 크게 하는 것 이외에 도구를 선택하기 까지 필요한 평균 시간을 단축하는 단계는 무엇이 있을까?

3. 오른손잡이 사용자들은 1600x1200 큰 화면에서도 정확히 가운데를 10픽셀 이내 오차로 짚어낼 수 있다고 한다. 만약 화면 어딘가에 1픽셀 짜리의 목표물을 배치하고, 사용자는 정확히 그 목표물 위에 마우스 포인터를 올려놓아야 한다고 했을 때, 전체 화면에서 사용자가 가장 빨리 접근할 수 있는 5군데를 나열하라. 가장 빨리 접근할 수 있는 위치부터 가장 느린 곳까지 순서대로 나열하면 추가 점수가 주어진다.

4. 마이크로소프트는 작업 표시줄(Taskbar-주로 윈도즈 하단에 붙어서 사용자가 최소화한 창이나 응용 프로그램을 열어볼 수 있게 하는 바)을 화면의 윗부분, 또는 옆이나 하단에 둘 수 있으고. 이 작업 표시줄은 숨겨두거나 항상 보이게 설정할 수 있다. 이 작업 표시줄 자동 숨김 기능이 극도로 비효율적인 이유를 최소한 두 개 이상 말해보라.

5. 윈도우의 풀다운 메뉴보다 매킨토시의 풀다운 메뉴에 최소한 다섯 배 더 빠르게 접근할 수 있는 이유를 설명해보라. 왜 마이크로소프트사가 이렇게 어리석은 결정을 내릴 수 밖에 없었는지 최소한 두 가지 이유를 말하면 추가 점수가 주어진다.

6. 계층 구조의 메뉴에서 병목 구간은 어디인가? 그리고 이 구간의 문제점을 최소화 시키기 위해 어떤 방법을 쓸 수 있을까?

7. 일렬 배열된 팝업 메뉴보다 원형으로 배열된 팝업 메뉴가 좋은 점을 하나 이상 말해보라

8. 일렬로 배열된 팝업 메뉴에서 모든 옵션에 접근하는 시간이 비슷해지도록 접근 시간 간의 균형을 맞추려면 무엇을 해야 할까?

9. 제품 디자이너들은 맥 키보드에서 기능 키의 크기를 반으로 줄여서 키보드의 전체적인 높이를 기능키 높이의 절반만큼 줄였다. 왜 이것이 어리석은 결정이었나?

10. 이 모든 문제를 해결할 수 있는 공통적인 해결책은 무엇인가?


만약 마지막 문제에 대답할 수 없다면, 아마 모든 문제가 다 어려웠을 것이다. 당신만 그런 것은 아니다. 마이크로소프트에서는 아마 대답할 사람이 하나도 없을 것이고, 애플에서도 대답할 수 있는 사람의 수가 점점 줄어들고 있다는 많은 증거들이 있으니까!

물론 마이크로소프트에서는 변명의 여지가 있다. 그 사람들은 초기부터 마우스를 포함한 잡동사니 시각적 인터페이스보다 키보드 인터페이스가 더 우수하다고 주장했으니까, 진짜 GUI를 만드는 것은 바보같다고 느꼈을 것이다. 시각적 인터페이스를 계속 억지로 만들다보니 이렇게 되었을지 모른다.

애플에서 왜 이렇게 되었는지는 조금 모호하다. 애플의 외주 디자이너들은 항상 인간 공학(Human Factors)에 대해 무지하거나 적대적이었는데, 최근에는 내부 디자이너들도 그런 것 같다. 빠르게 접근할 수 있는 레이블들을 계층 구조로 만들어 5배에서 10배나 느리게 만드는 걸 보면.



해답
먼저, 다른 모든 문제들이 10번 문제의 답인 Fitts의 법칙을 중심으로 돌아가기 때문에 10번 문제부터 시작해보자. 지난 글 디자인의 기본원리(First Pinciples of Design, 피엑스디 설명 참고) 에서 언급했듯 Fitts의 법칙은 다음과 같다.


Fitts의 법칙: 목표물까지 도달하는데 걸리는 시간은 목표물까지의 거리와 목표물 크기의 함수이다


이 작지만 아주 명확한 법칙은 가끔은 고의인지 의심이 될 정도로 자주 무시된다. 물론 대개는 과학적 사실이나 공부와는 담을 쌓은채 얄팍한 믿음으로 부풀려진, 전반적인 무지를 나타내는 것이겠지만.

그러나 다행스럽게도, AskTog의 독자들은 총명한 만큼 집요함도 지녔기 때문에 Fitts의 법칙이 무엇인지 이미 정확히 알고 있거나, 오늘 밤 잠들기 전에 알게 될 것이다.


Fitts의 법칙은 단순하고, 확실하며 불변의 법칙이다. 이 법칙이 질문에 어떻게 적용되는지 살펴보도록 하자.
 (영어로는 Fitts' Law 라고 쓴다, 엄밀히 말하자면 Fitts's Law라고 쓰는 것이 맞지만 영어 문법상 그렇게 표시하지 않는다.)



Question 1
마이크로소프트 툴바는 사용자들에게 각 도구명을 도구 하단에 레이블로 표시할 것인지에 대한 옵션을 제공한다. 레이블이 없을 때 보다는 있을 때 도구를 더 빨리 선택할 수 있는 이유를 한 가지 이상 말해보라. (사용자는 각 도구를 알고 있으며 필요한 도구를 찾는데 레이블은 필요하지 않다는 추정 하에 답해 보라)

다음의 두 가지가 답이 될 수 있다. 이 밖에도 더 많은 이유가 있을 수 있다.

A.  레이블이 목표물(마우스 클릭 가능 지역)의 일부분이 된다. 따라서 목표물의 크기가 커지는 셈이고, Fitts의 법칙에 따르면 목표물의 크기가 클수록 더 빨리 도달할 수 있다.
B.  레이블이 없으면 각 도구의 아이콘들이 조밀하게 모여있게 될 것이다.

처음에는 목표물간의 거리가 좁아지므로 아이콘들이 한데 모여 있는 것이 더 유리해 보일 수 있다. 하지만 여기서 주의해야 할 점은 사용자의 작업이 어느 한 목표물에서 다음 목표물로 옮겨가는 것이 아니라는 점이다. 사용자가 툴바를 사용해야겠다고 결정한 순간에 마우스 포인터는 목표물과는 많이 떨어진 콘텐트 영역 내에 있었을 것이다.

아이콘들이 따로 떨어져 흩어져 있을 때, 아이콘과 아이콘 사이에 잘못 눌렀을 때 아무런 반응도 일어나지 않는 완충 지대가 생긴다. 하지만, 만약 아이콘들이 다닥다닥 붙어있게 되면 원하지 않은 버튼을 선택하여 실행시킬 확률이 높아진다. 이러한 오류가 일어날 가능성을 피하기 위해 레이블이 없는 툴바를 사용하는 사람들은 속도를 늦추는 것을 익히게 된다. (그들에게 느리게 했는지 묻지 않는 것이 좋다. 그들은 분명 더 빠르게 했다고 답할 것이다. 물론 스톱워치는 진실을 알고 있다.)

목표물의 크기를 크게 하는 또 다른 방법은 당연히 작은 아이콘보다 큰 아이콘을 선택하는 것이다. (4x4픽셀 아이콘을 사용하면서 자기가 빠르게 작업하고 있다고 착각하는 파워유저에게는 안타까운 소식이다)



Question 2
그래픽 프로그램에, 16x16픽셀 아이콘이 2x8(가로2줄, 세로 8줄로 16개)로 배열되어있는 도구 팔레트가 화면 왼쪽 가장자리에 배치 되어있다. 도구 팔레트의 위치를 변경하거나, 아이콘의 크기를 더 크게 하는 것 이외에 도구를 선택하기 까지 필요한 평균 시간을 단축하는 단계는 무엇이 있을까?

A.  배열을 2x8에서 1x16로 바꾸어 모든 도구가 화면 가장자리를 따라 1열로 배치되도록 한다.
B.  사용자가 도구를 선택할 때 화면의 가장 왼쪽 가장자리에 있는 첫 번째 픽셀을 선택할 수 있도록 한다. 즉, 화면의 가장자리에 빈틈이 있으면 안 된다.

두 번째 단계는 매우 중요한데, 자주 무시되는 단계이기도 하다.

Fitts의 법칙은 목표물까지 도달 시간은 거리와, 목표물의 크기에 대한 함수임을 기억하라. 목표물의 크기가 크면 시간이 단축된다. 원리는 매우 간단하다. 목표물의 크기가 커지면 사용자는 잘못 선택할 염려가 줄어들어 목표물을 향해 갈 때 속도를 줄일 필요가 없기 때문이다.

이제, 화면 가장자리를 생각해보자. 목표물의 폭이 얼마나 되는가? 만약 목표물이 정말 1픽셀만 보인다면, 목표물을 선택하기가 매우 힘들 것이다. 하지만 실제 사용할 때 보면, 화면 가장자리는 무한히 깊은 공간이 펼쳐져 있는 것이나 다름없다. 마우스로 화면의 가장자리를 클릭할 때 얼마나 빨리 움직이느냐 하는 것은 문제되지 않는다.  마우스 포인터는  (아무리 빨리 움직이더라도 속도를 줄일 필요없이-역자주) 정확하게 화면 가장 자리를 선택할 것이고, 절대 화면 가장자리를 지나 밖으로 벗어나지 않을 것이기 때문이다. 화면 가장자리에서 1픽셀이나 2픽셀 떨어진 곳을 클릭하는 것이 화면 가장자리를 클릭하는 것보다 훨씬 오래 걸린다. 화면 가장자리 영역을 사용하라. 그 영역은 당신의 친구 같은 존재이다.


Question 3
오른손잡인 사용자들은 1600x1200 큰 화면에서도 정확히 가운데를 10픽셀 이내 오차로 짚어낼 수 있다고 한다. 만약 화면 어딘가에 1픽셀 짜리의 목표물을 배치하고, 사용자는 정확히 그 목표물 위에 마우스 포인터를 올려놓아야 한다고 했을 때, 전체 화면에서 사용자가 가장 빨리 접근할 수 있는 5군데를 나열하라. 가장 빨리 접근할 수 있는 위치부터 가장 느린 곳까지 순서대로 나열하면 추가 점수가 주어진다.

속임수가 있는 질문은 아니다. 그리고 질문의 첫 번째 부분에 대해서는 어떤 인터렉션 디자이너든지 바로 대답할 수 있어야 한다. 추가 점수가 주어진 질문은 그리 단순하지 않다. 하지만 이 질문에 대한 대답은 “5 magic pixel”이라고 불리는 지점이다.

가장 빠르게 도달할 수 있는 지점은 현재 마우스 포인터가 위치한 지점이다. 마우스가 어디로 움직이든지 현재의 마우스 위치에 나타나는 팝업 메뉴(이른바 콘텍스트 메뉴 혹은 우클릭 메뉴-역주)가 이 지점을 잘 활용하는 대표적인 예이다. 이 지점은 마우스가 목표물을 향해 움직일 필요가 없으므로 무한히 큰 목표물이라고 할 수 있겠다. 이 지점은 실수할 수가 없다.

평균적으로 나머지 네 픽셀은 마우스 포인터에서부터 멀찍이 자리잡고 있다. 그러나 그 거리는 목표물의 크기로 충분히 만회할 수 있는 정도이다. 왜냐하면 목표물은 두 방향으로 무한히 크기 때문이다. 이 Magic pixel은 화면의 네 귀퉁이이다. 마우스 커서를 원하는 아무 방향으로 내던져보라. 만약 충분한 속력을 실어서 했다면 마우스가 이상하게도 항상 어느 한 쪽 귀퉁이에 가 있는 것을 보게 될 것이다. 정상적으로 디자인된 마우스라면 가속 기능이 있기 때문에 예상되는 결과이다.

추가 점수가 있는 질문의 힌트는 사용자가 오른손잡이라는 데에 있다. 오른손잡이는 이미 언급한 지점을 포함해서 다음과 같은 순서로 점점 접근의 어려움을 느끼게 된다.

A.  현재 마우스 커서가 있는 곳: 그 자리에서 마우스를 클릭하기만 하면 된다.
B.  우측 하단 코너
C.  좌측 상단 코너
D.  우측 상단 코너
E.  좌측 하단 코너

만약 마우스를 오른손에 쥐고 손목과 손만 사용해서 위의 네 방향으로 움직여보면, 팔의 움직임에서 이유를 찾을 수 있을 것이다. 물론 왼손잡이는 반대의 순서로 어려움을 느낀다.

네 방향에 따른 차이점은 “magic pixels”의 영향력에 비교해보면 상대적으로 작다. 화면의 네 귀퉁이 모두 잘 사용되어야 한다.
(Windows 7을 보면, 좌하단에 시작 버튼, 우하단에 바탕화면 보기 버튼을 배치하여, 이것을 활용하고 있다.-역주) 


Question 4
마이크로소프트는 작업 표시줄(Taskbar-주로 윈도즈 하단에 붙어서 사용자가 최소화한 창이나 응용 프로그램을 열어볼 수 있게하는 바)을 화면의 윗부분, 또는 옆이나 하단에 둘 수 있으고. 이 작업 표시줄은 숨겨두거나 항상 보이게 설정할 수 있다. 이 작업 표시줄 자동 숨김 기능이 극도로 비효율적인 이유를 최소한 두 개 이상 말해보라.

지금쯤 부터는 점점 답하기가 수월해 질 것이다.

A. 화면의 가장자리는 화면에서의 최상의 부지이다. 스무 개가 넘는 빠른실행 아이콘을 배치할 수 있는 자리를 작업 표시줄 하나만을 배치하는데 낭비하지 말아야 한다.
B. 작업 표시줄의 자동 숨김 기능은 실수로 숨겨진 작업 표시줄을 나타내게 하기 쉽다. 사용자는 화면 가장자리 근처에 있는 무언가를 선택하려고 할 때마다 계속 작업 표시줄을 열게 된다.
C. 작업 표시줄은 이 중 어떠한 문제도 일으키지 않는 것이 좋지만, 만약 작업 표시줄이 화면의 4 귀퉁이 중 한 곳에 위치한다면 더 빠르게 접근할 수 있을 것이다. 예를 들어, 마우스를 좌상단으로 휙 보내는 것 만으로 작업 표시줄을 오조작 없이 빠르게 불러올 수 있을 것이다. 
(Windows 8에서 좌하단 등을 이렇게 사용하고 있다-역주)


Question 5
윈도우의 풀다운 메뉴보다 매킨토시의 풀다운 메뉴에 최소한 다섯 배 더 빠르게 접근할 수 있는 이유를 설명해보라. 왜 마이크로소프트사가 이렇게 어리석은 결정을 내릴 수 밖에 없었는지 최소한 두 가지 이유를 말하면 추가 점수가 주어진다.

마이크로소프트, SUN, 그리고 다른 회사들은 메뉴바를 애플처럼 화면의 가장 위에 두는 대신, 개별 윈도우에 넣기로 결정하였다. 그들은 두 가지 이유에서 이러한 결정을 내렸다:

A. 애플은 화면 상단의 메뉴바에 대해 특허권과 저작권을 주장하였다
B. 다른 모든 사람들은 메뉴바를 개별 윈도우의 상단에 넣으면 사용자에게 더 가까워져서 더 빨리 사용할 수 있을 것이라고 예상했다.

첫 번째 이유에 대해서는 변호사들이 이미 한바탕 논의하였으니, 두 번째 이유를 살펴보자. 애플의 메뉴바는 윈도우에 있는 메뉴바 보다 훨씬 빠르다. 왜일까? 메뉴바가 화면의 가장자리에 위치해 있어서 마우스 커서가 메뉴바를 지나 화면 가장자리를 뚫고 화면 밖으로 사라지는 일은 없을 것이고, 따라서 메뉴바의 높이가 무한한 것이나 다름없으니까, 사용자들은 심지어 그냥 마우스를 위로 던져도 쉽게 실수없이 접근할 수 있기 때문이다.

필자는 애플에서 모니터를 위, 아래로 두 개 배치 한 다음 메뉴바를 아래 쪽에 있는 모니터 상단에 나오게 한 뒤, 사용성 테스트를 진행 했었다. 테스트에서 사용자들이 위쪽 모니터로 갈 수 있는 유일한 방법은 메뉴바를 지나서 가는 것뿐이었다.

그 다음에 사용자들이 계속해서 메뉴바를 선택하도록 하는 과제를 주었다. 처음에 피실험자들은 단지 마우스를 움직이는 속도가 너무 빨랐기 때문에 평균 9인치(약20cm) 정도 위 쪽 모니터로 넘어갔다. 그 다음부터 피실험자들은 속도를 줄여서 메뉴바를 정확히 짚어내야 한다는 것을 학습했다. 그 때부터 피실험자들은 환경에 적응하여 메뉴 접근 속도가 눈에 띄게 느려져서, 윈도우 사용자들과 비슷한 수준까지 느려지게 되었다.

메뉴바가 각 창에 위치해서 좋은 점은, 사용자들이 하고 있는 작업에 필요한 특정 도구를 어디서 찾아야 하는지 알기 쉽다는 점이다. 이것은 어리석은 짓이다. 사용자들은 주어진 창 안에서 다양한 업무를 수행하고, 업무에 따라 메뉴의 내용도 바뀔 것이다. 뿐만 아니라, 이상하게 삐뚤어진 응용 프로그램들도 많이 존재한다. 특히 Sun에서 메뉴바는 현재 작업하고 있는 창에 있지도 않다.  정말 기이하지 않을 수 없다.

마이크로소프트의 응용프로그램은 전체화면 모드일 때 화면의 가장 상단에 메뉴바를 제공하기 시작했다. 워드나 엑셀에서 이 메뉴바를 사용해보라. 기존의 메뉴바 보다 훨씬 빠르다. 그런데, 마이크로소프트 Visual Studio의 메뉴바는 다 된 밥에 코 빠뜨린 격으로 화면 가장자리와 메뉴바 사이에 1픽셀의 경계가 있다. 마이크로소프트의 무지함이 이토록 적나라하게 드러난 적이 없었다.



Question 6
계층구조의 메뉴에서 병목 구간은 어디인가? 그리고 이 구간의 문제점을 최소화 시키기 위해 어떤 방법을 쓸 수 있을까?

병목 현상이 일어나는 구간은 첫 번째 레벨의 메뉴에서 두번째 레벨의 메뉴로 가는 길목이다. 사용자들은 처음에 마우스 포인터를 아래쪽으로 움직여 하위 메뉴를 포함한 메뉴까지 가야한다. 그 다음 사용자는 하위 메뉴에 진입하기 위해서 마우스를 아주 조심스럽고 정확하게 수평으로 움직여서 하위 메뉴로 마우스 포인터를 옮겨야 한다.

처음 이 계층구조를 발명한 개발자의 팔뚝은 트랙 위에 고정되어 있어서 수직 방향으로는 조금도 움직이지 않고 완벽하게 수평으로 팔을 움직이는 것이 가능했던 것 같다(!). 하지만 우리들 대부분의 팔뚝은 회전 관절인 팔꿈치에 고정되어있다. 따라서 우리의 팔은 수평으로 직선을 그리며 움직이기보다는 호를 그리며 움직이게 되어있다. 이런 우리들에게 마우스 커서를 직선으로 움직이도록 하는 것은 잘못된 것이다. 우리가 아무리 수평으로 움직이려고 해도 마우스 커스는 자연스럽게 약간 아래로 치우치게 될 것이다. 그리고 마우스 포인터가 아래로 치우치게 되면 (포인터가 다른 메뉴 영역으로 움직여 버려-역주) 하위 메뉴는 마우스 커서가 도달하기 전에 닫혀버리고 말 것이다.

윈도우즈 팀은 이러한 문제를 다음과 같은 방법으로 극복하고자 하였다. 만약 사용자가 첫 번째 레벨의 메뉴에서 마우스 커서를 아래쪽으로 움직여도 하위 메뉴가 곧바로 닫히지 않게 하였다. 그리고 하위 메뉴를 약 0.5초 정도 닫지 않은 채로 유지하였다. 따라서 사용자가 빠르게 마우스를 이동시킨다면 정확히 움직이지 않아도 하위 메뉴가 닫히기 전에 하위 메뉴로 진입할 수 있었다. 하지만 불행하게도 하위 메뉴로 진입할 가능성을 높이기 위해 사람들이 선택한 방법은 더 빠르게 움직이기보다는 속도를 늦춰 천천히 움직이는 것이었다. 마우스 커서를 빠르게 이동시키는 것이 이 문제를 해결할 수 있다는 것을 아는 사람은 거의 없었다. 마이크로소프트의 해결책은 잘못된 것이었다.

필자가 1980년대 중반에 맥의 계층 메뉴 알고리즘을 구체적으로 명시하였을 때, 사용자들이 원하지 않는 메뉴로의 이동을 두려워 하지 않고서 계층메뉴에 접근할 때 오류가 더 잦아지기 때문에 < 모양의 완충구간의 필요성을 느꼈다. 만약 사용자가 메뉴에서 서너 픽셀까지만 아래로 움직이는 한 하위 메뉴는 닫히지 않는다. (하위 메뉴를 닫는것도 어렵지 않다, 의도적으로 위, 아래 항목으로 움직이면 된다) 애플의 계층 메뉴는 하위 메뉴라는 개체가 추가되기 때문에 여전히 단일 계층 메뉴보다는 비효율적이지만, 평균적인 비디오 게임보다는 쉽다.

안타깝게도, NeXT사람들은 OSX의 계층 메뉴 인터페이스를 디자인 할 때 맥이 아닌 윈도우의 계층 구조를 그대로 가져왔다. 오늘날 맥의 계층메뉴는 딱 윈도우의 계층 메뉴만큼 사용하기 어렵다.

Fitts의 법칙은 목표물의 크기와 거리에 대한 것 만은 아니다. Fitts의 법칙은 목표물의 갯수에 대해서도 정의 하고 있다. 목표물의 갯수가 많을수록 업무 수행에 걸리는 시간이 더 오래 걸린다. 이와 같은 정의로부터, 계층구조를 가진 메뉴는 하위메뉴를 추가함으로써 목표물의 갯수가 늘어났으므로 작업 시간이 더 오래걸린다고 할 수 있다. 복수 개의 목표물에 대한 질문과 대답

대부분의 경우에, OSX 이전에 내가 설계한 계층 구조 메뉴를 사용할 때 사용자들은 하위 메뉴를 정확히 조준하는것에 대해서는 생각도 해보지 않았다. 하위 메뉴가 열리면 사용자들은 원하는 옵션을 향해 바로 마우스 커서를 가져갔다. 사용자가 하위 메뉴를 따로 분리시켜서 생각할 경우는 하위 메뉴에 항목이 너무 많아서 사용자가 원하는 메뉴가 너무 위쪽에 있을 때나 너무 아래쪽애 멀리 떨어져 있을 때 뿐이었다. 하지만 이 경우에도 조심조심 수직/수평으로 움직이는 대신,  큰 호를 그리며 원하는 메뉴를 향해 마우스를 움직이면 되었다.

사용자들의 움직임을 디자인 할 때에도 필요한 움직임의 개수, 움직여야 할 거리, 요구되는 움직임의 정확성을 줄여라. 그 다음 그 움직임들이 사람들의 실제 움직임에 어떻게 반영할 것인지 생각해보라.


Question 7
일렬 배열된 팝업 메뉴보다 원형으로 배열된 팝업 메뉴가 좋은 점을 하나 이상 말해보라

만약 선택 가능한 옵션들이 사용자의 위치를 기준으로 하여 원형으로 배열된다면 원하는 옵션을 선택하기 위해서 한 두 픽셀만 움직여 피자 조각 형태의 메뉴 안에 넣으면 될 것이다. 적은 거리를 이동하고, 목표물의 크기도 적당한 좋은 디자인이다.

이러한 팝업 배열은 또 다른 이점을 가지고 있는데, 거리와 방향정보가 운동기억에 저장된다는 것이다. 만약 충분히 적당한 개수의 옵션이 제공된다면 인쇄를 하기 위해서는 좌측 상단으로 마우스를 움직이고, 팩스를 보내기 위해서는 우측 하단으로 마우스를 움직여야 한다는 사실을 금방 (근육이) 학습 하게 될 것이다. 간단한 제스쳐를 학습한 다음부터는 사용자가 자신이 원하는 것이 무엇인지 확신하지 못하여 오랫동안 망설이는 경우를 제외하고서는 굳이 메뉴를 띄울 필요도 없어질 것이다. (이 사실은 1980년도 후반에 애플에서 진행된 Fabrik 프로젝트의 과정에서 증명되었다)



Question 8
일렬로 배열된 팝업 메뉴에서 모든 옵션에 접근하는 시간이 비슷해지도록 접근 시간 간의 균형을 맞추려면 무엇을 해야 할까? 

마우스 포인트에서 멀리 떨어져 있을수록 옵션의 크기를 더 크게 조절하면 된다. 멀리 떨어져 있다고 잘 안 보이는 것도 아니니까, 정말 물리적인 크기를 크게 할 필요는 없다. 대신, 마우스를 스크린에 맵핑할 때 그렇게 할 수 있다는 것이다. 예를 들어 마우스를 아래쪽으로 멀리 떨어져있는 옵션으로 가져갈 때, 화면에서 보이는 것 보다 실제로 더 많은 거리를 움직이게 만들면 된다. 시각적인 지표와, 행동적인 지표를 분리시키는 셈이다.

또 다른 분리의 예로, 국부 중력을 적용하는 것을 들 수 있다. 마우스 포인터가 특정 개체에 가까이 가져가면 개체로 끌려가도록 하는 방법이다. 하지만 이 방법에는 장애요소가 매우 분명하다. 마우스가 특정 목표물에 걸려든 이상 해당 개체를 벗어나 다른 쪽으로 지나가는 것이 쉽지 않기 때문이다. 압력 감지 마우스가 있다면 눌러서 중력 작용을 켜거나 끄게(특정 개체에 끌려가게 되거나, 중력의 영향권 밖을 다니게) 할 수는 있다

독자 Victor Zambrano는 목표물까지의 접근시간을 줄이는 또 다른 기술을 제시했다. 아래 Victor가 제시한 것처럼 종속 메뉴를 가운데 정렬해서 어떤 항목도 마우스에서 전체 목록의 절반 이상을 벗어나지 않도록 하는 것이다.



Victor가 제시한 것은 풀다운 메뉴에는 잘 적용되지 않았다(상위 메뉴가 아주 긴 경우에만 적용이 된다). 그러나 팝업이나 컨텍스트 메뉴에는 최적의 방법이었다. 단지, 가장 중요한 메뉴가 목록의 가운데 오도록해서 가장 빨리 접근할 수 있도록 하는 것이 중요하다.



Question 9
제품 디자이너들은 맥 키보드에서 기능 키의 크기를 반으로 줄여서 키보드의 전체적인 높이를 기능키 높이의 절반만큼 줄였다. 왜 이것이 어리석은 결정이었나? 

일정한 접근 시간을 유지하기 위해서는 목표물이 멀리 떨어져 있을 수록 크기가 커져야 한다.  디자이너들은 목표물의 전체적인 크기를 줄이는 치명적인 실수를 저질렀다. 그들은 키보드의 경사를 뒤로 갈 수록 급격히 높아지게 해서 손가락을 몇 도 올리는 것 만으로도 숫자 키나 기능 키에 닿을 수 있게 했어야 한다. 이 방법으로 정확도와 속도를 동시에 높일 수 있었을 것이다.



Question 10
이 모든 문제를 해결할 수 있는 공통적인 해결책은 무엇인가?

이제 여러분 모두가 정답은 Fitts의 법칙이라는 것을 알 것이다. 그리고 여러분은 이 원리를 새로운 운영체제를 디자인 할 때라든지, 새 웹 페이지의 레이아웃을 구상할 때 늘 적용시킬 수 있을 것이다. 만약 2글자밖에 없는 디폴트 OK 버튼이 매우 작게 만들어진다면, 양 쪽에 빈칸을 몇 칸 더 넣어서 채워 넣는 것을 고려해보라. 만약 당신이 스크린 내 환경을 컨트롤 할 수 있고, 팔레트를 배치하기로 한다면 팔레트를 화면 가장자리에 위치할 수 있도록 만들어서 사용자들이 각 도구를 선택할 때, 쉽게 사용할 수 있도록 하라. 그리고 만약 화면의 가장 윗부분에 메뉴바를 둘 수 있다면 활용하라! 아이콘이나, 버튼 뭉치보다 훨씬 간편하고, 만약 사용자 테스트를 할 수 있다면 훨씬 빠르다는 것도 알게 될 것이다. 또한, 만약 애플이나 마이크로소프트에서 일하고 있다면, 인터랙션디자인에 대해서는 관련 지식을 가지고 있는 사람들의 이야기에 귀 귀울여보라. 그런 사람들이 분명히 존재하며, 필자도 그들과 이야기를 나누어 보았다. 여러분도 그들과의 대화를 시도해보길 바란다.

마지막으로, 시험에 참여해주고 여기 있는 해설에 있는 정답들 중 필자가 생각지 못한 또 다른 정답들을 찾아준 Frank Ludolph와 Craig Oshima에게 감사를 표한다.

만약 Fitts의 법칙에 대해 더 알아보고 싶다면,
Walker, Neff, Smelcer가 쓴 "A Comparison of Selection Time from Walking and Bar Menu"(1990)
Proceedings of CHI'90의 221~225페이지를 읽어볼 것을 권한다.

여러분은 문제를 어떻개 풀었는가? 여기서 가장 중요한 것은 만약 위의 열 문제 중 열문제 모두를 이해하고, 답할 수 있다면 여기서 배운 것들을 실제 디자인에 적용시킬 수 있다는 신호이다.

---------

On Sep 20, 2012, at 10:47, Jay Yi wrote:

저희 독자 중 한 명이, 아래 내용을 읽고, 피츠의 법칙이 타겟의 개수과 관련이 있는가?하고 질문을 보내왔습니다.

Fitts의 법칙은 목표물의 크기와 거리에 대한 것 만은 아니다. Fitts의 법칙은 목표물의 갯수에 대해서도 정의 하고 있다. 목표물의 갯수가 많을수록 업무 수행에 걸리는 시간이 더 오래 걸린다. 이와 같은 정의로부터, 계층구조를 가진 메뉴는 하위메뉴를 추가함으로써 목표물의 갯수가 늘어났으므로 작업 시간이 더 오래걸린다고 할 수 있다. 원문보기

제가 알기로, 피츠의 법칙은 타겟의 개수와는 상관이 없는데, 위 부분을 좀 더 설명해 주시겠어요?

Regards,
Jay


On Fri, Sep 21, 2012 at 11:51 AM, Bruce Tognazzini wrote:

피츠의 법칙은 하나의 타겟에 도달하는 시간을 예측하는 것이지만, 사용자가 하나 이상의 타겟을 건드려야할 때, 개별 타겟에 도달하는데 걸리는 피츠 법칙 시간을 함께 더하여 합계를 내어서 전체 태스크를 완성하는데 걸리는 시간을 예측할 수 있습니다. 이런 경우가 실제로 생기면 골치 아프죠. 예를 들어 계층 구조 메뉴를 잘 못 만들면, 4개의 구분된 타겟(메뉴 이름, 상위 메뉴 이름, 하위 메뉴로 가는 아주 얇은 수평 통로, 마지막으로 하위 메뉴 내의 원하는 메뉴 아이템)을 필요로 하게 됩니다.

피츠의 법칙을 활용하는 방법 중 하나는 먼저 가능하면 많은 타겟을 없애는 것입니다. 남은 타겟을 되도록이면 크고 가깝게 만드는 일은 그 다음이 되겠지요. 예를 들어, 내가 맥에 계층 메뉴를 설계했을 때는, 수평으로 조심스럽게 움직일 필요없이, 상위 메뉴 이름에서 바로 갈 수 있게 설계했습니다.(불행하게도 시스템 X로 가면서 없어져 버렸지만)

결론적으로 독자의 질문이 맞습니다. 피츠는 단일 타겟을 다루고 있죠. 하지만 우리는 대개 여러 개의 타겟을 다루게되고, 그러다보면 각 타겟에 빨리 도달할 수 있게 설계해야할 뿐만 아니라, 되도록이면 타겟을 완전히 없애 버리도록 노력해야합니다. 원문보기

Sent from the iPad 3 of Bruce Tognazzini

[참고##UI법칙##]

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 3
Ad Test...
2012.09.19 08:21

피츠의 법칙 Fitts' Law

UI 디자인을 하다보면, 거의 매순간 필요한 정말 중요한 법칙이 피츠의 법칙인데, 정작 많은 UI 디자이너들이 잘 모르고 있다. 혹은 알고 있더라도, 간단한 의미 정도만 알고 있을 뿐, 이것이 얼마나 중요하고도 일상적으로 필요한지를 모르는 경우가 많다.(정말 자기가 잘 아는지 확인해보고 싶으면 피츠를 위한 퀴즈를 풀어보자) 이 글에서는, 피츠의 법칙을 잘 모르면 UI 디자이너가 아니라고 할 정도로 손에 꼽을 수 있는 중요한 이 법칙을 간략하게 설명하고자 한다.


우선 위키피디아의 정의를 찾아보자

피츠의 법칙(Fitts' Law)은 사용성 분야에서 인간의 행동에서 대해 속도와 정확성간의 관계를 설명하는 기본적인 법칙이다. 시작점에서 목표로 하는 지역에 얼마나 빠르게 닿을 수 있을지를 예측하고자 하는 것이다. 이는 목표 영역의 크기와 목표까지의 거리에 따라 결정된다. 이 법칙은 폴 피츠에 의해 1954년에 발표되었다.

오른쪽 그림에서 살펴보면,

먼저 마우스 포인터가 현재 A 지점에 있다고 가정해 보자. 그런데 B 버튼을 클릭해야 한다. 그러면 사용자는 얼마의 시간이 걸릴까? 사용자가 A에서 B의 중심부를 향해, 붉은 색 점선 화살표를 따라 마우스를 이동한다고 할 때 걸리는 시간 T는, A 에서 B 중심부 까지의 거리인 D 가 멀면 멀수록 더 오래 걸리고, 가까우면 덜 걸릴 것이다. 즉 D에 비례하는 함수이다.

그런데 마우스 포인터가 B 근처에 도달하면, 사용자는 B를 지나쳐서는 안되기 때문에 자기도 모르게 속도를 줄이게 된다. 즉 B의 중심점을 기준으로 허용하는 폭인 W는 크면 클 수록 속도를 줄이지 않고 빠르게 간 다음 클릭하면 되기 때문에, W가 크면 시간은 줄어들고, W가 작으면 시간은 더 오래 걸린다.

결국 종합하면,
피츠의 법칙이란, 떨어진 영역을 클릭하는데 걸리는 시간은, 영역까지의 거리와 영역의 폭에 따라 달라지는데, 멀리 있을수록, 버튼이 작을 수록 클릭하는데 시간이 더 많이 걸린다
는 것이다. 어라? 너무 상식적이지 않은가? (유명해지려면 상식적인 일을 해야한다. 피츠는 이에 관해 단 두 편의 논문을 썼지만, 이에 관한 후속 연구자들의 논문은 수천편을 넘는다.) 문제는 이 상식적인 일이 지켜지지 않는 경우가 많다는 점이다. 손으로 조작하는 인터페이스 설계에서 버튼을 만드는 디자이너들이 버튼 안에 들어갈 글자만 생각하다보면, 더 빈번하게 눌리는 버튼이 단어 길이가 짧다는 이유만으로 더 작아지는 경우가 허다하다. 예를 들면 OK 버튼이 CANCEL 버튼 보다 글자 수가 작으니까 더 작아져 버리는 것이다.

이제 피츠의 법칙에 대해 대강이나마 이해했다면, "정말" 자기가 이해하고 있는지 알아보기 위하여, 피츠를 위한 퀴즈를 풀어보기 바란다.


피츠의 법칙에서 흔히 잘못 알고 있는 4가지
1. Fitt's Law가 아니다. 원래 이름은 Paul M. Fitts이며 따라서 Fitts' Law 혹은 Fitts's Law라고 써야 한다. 영어 표기법에 따라 두 가지 모두 허용한다고 보면 되는데, 우리말로는 피츠의 법칙이라고 쓰면 적당할 것 같다.
2. 단순 가로 폭이 아니고, 움직이는 방향의 폭이다. 즉 위 그림에서 B 버튼의 가로 너비에 반비례하는 것이 아니라, W에 반비례하게 된다.
3. 피츠의 법칙은 원래 마우스 움직임과는 관련이 없었다. 즉 HCI의 법칙이 아니었다. 1954년에 처음 피츠는 손으로 점을 찍는 것과 물건을 움직이는 것 등을 대상으로 연구했으며, 따라서, 화면상의 마우스 포인터, 그것도 가속도 기능이 있는 마우스 움직임이나, 손가락만 움직이는 터치폰에서 적용하는 것은 비슷한 원리로 유추하여 발전시킨 것이다. HCI에 처음 적용된 것은 1978년 Card 등에 의해서이다.  
4. 피츠의 관심은 1차원 선상에서의 움직임이었다. 제대로 하려면 2차원으로 생각해야 하는데, 2차원으로 확대하여 설명하는 이론들도 많고, 잘 설명이 되지만, 굳이 그렇게까지 할 필요를 못 느끼므로 모두 1차원만 설명하는 것이다.


[참고1]
이 법칙은 몇 가지 다른 방법으로 수학 공식화할 수 있는데 대표적인 것은 뉴욕대 교수 스콧 맥켄지의 샤논 공식으로, 피츠 자신의 공식보다 더 잘 활용된다.

T = a + b \log_2 \left(\frac{D}{W}+1\right)

여기서,
T 는 동작을 완수하는 데 필요한 평균 시간
D 는 대상 물체의 중심까지 거리
W 는 움직이는 방향을 축으로 하였을때 측정되는 목표물의 폭이다.
(a 와 b 는 실험 상수로서 상황이 정해지면 그에 따라 실험 결과로 정해진다.)

더 자세한 내용은 스콧 맥켄지(http://www.yorku.ca/mack/)의 박사 논문을 보면 된다.

[참고2]
피츠를 위한 퀴즈
Fitts's Law (Wikipedia)
제대로 베끼기 - 마이크로소프트, 애플, Fitts' Law.

[참고##UI법칙##]



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 3
Ad Test...
2012.03.11 12:37

[독후감]사람에 대한 100가지 사실

모든 기획자와 디자이너가 알아야 할
사람에 대한 100가지 사실

100 Things Every Designer Needs to Konw About People
수잔 웨인쉔크(Susan M. Weinschenk) 지음, 이재명,이예나 옮김.

그러니까 이 책에 대한 나의 한줄평은 다음과 같다. 책 제목대로,
"모든 디자이너가 읽어야 한다"

디자이너들은 대개 자신의 주장을 논리적으로 전개하고, 의미있는 근거를 제시하는데 서투르다. 그래서 자기가 주장하는 것에 대한 근거가 될 만한 것들을 평소에 좀 알고 있어야 한다. 책을 한 번 읽고, 책꽂이에 꽂아 두었다가 때때로 사용할 수 있으면 좋을 것이다.

호평은 여기까지.
그럼 이 책을 보면서 우려되는 몇 가지 점을 추가하고 싶다.


1. 목차만 보고 '당연한 이야기 아냐?'하며 던져 버리지 말길.
물론 목차 가운데는 이런 것도 있다.
 
48. 큰 소음은 깜짝 놀라게 하고 주의를 끈다.
 
흠... 어떻게 보면 이 책은 사람이라면 누구나 알고 있는 사람에 대한 사실로 가득 차 있다. 물론 모든 이야기가 48번처럼 3살 때 알 수 있는 것은 아니고, 사춘기 때 알게 되거나 어른이 되어서 알게 된 이야기들도 있고, 뉴스나 다른 책을 통해서 알게된 사실들도 있다. 어쨌든 대부분의 내용이 어떻게 보면 너무 당연한 사실들이다.
하지만 모든 내용 하나하나가 단순하게 넘길 수 있는 일들이 아니다. 각 꼭지들마다 심도 깊은 연구를 통해서 밝혀진 내용들을 담고 있다. 아마 하나 하나가 어떤 사람에게는 평생의 연구 주제일 것이다. 그만큼 이 책은 방대한 연구를 포함하고 있다.
단순하게 넘겨버리지 말고, 자기가 하고 있는 일에 되새겨 본다면 큰 도움이 될 수 있다.


2. 그래서 한 페이지 읽었다고 아는 척 하지 말길.
 
주변에 이런 사람이 너무 많다. 아주 단순한 사실조차 증명하기 위해 많은 노력이 있었고, 그렇기 때문에 그 내용을 단순 요약한 한 페이지를 읽고 아는 척 하기에는 너무나 위험한 부분들이 많은데, 사람들은 단 몇 줄 읽고, 그것을 진실처럼 활용한다. 더군다나 사람들에 대한 생각은 아직 모르는 분야가 너무 많아서 함부로 판단을 내리기는 쉽지 않다. 그래서,
 
57. 사람들은 선천적으로 게으르다 / 77. 사람들은 바쁠 때 더욱 행복하다
50. 사람들은 목표에 더욱 가까워질수록 더욱 동기를 부여받는다. / 81. 달성하기 어려울수록 사람들은 좋아한다.

 
와 같이 언듯보면 전혀 반대의 이야기가 책의 곳곳에 있는 것 처럼 보여도 구체적으로 읽어 보면 각각의 의미가 전혀 다른 것인데, 대충 읽고 아는 척 하는 사람들은 필요에 따라 자기가 원하는 정반대의 이야기를 함부로 골라서 쓴다. 관심있는 주제가 나왔다면 적어도 이 책이 인용하고 있는 원 논문과 주요 레퍼런스 정도는 읽고 이야기를 하는 것이 좋을 것 같다. 이 책의 저자도 그렇게 활용되길 바랄 것이다.


3. 이 책의 내용이 진실이라고 믿지 말길.
아직 인간에 대한 연구는 미진한 것이 많다. 그리고 정말 그렇다고 믿기에는 아직 실험들이 너무 부족하고 약하다. 1956년 밀러(George A. Miller)가 발표한 논문에 포함된 '매직 넘버 7, 플러스 마이너스 2'는 오랜 동안 사람들이 진실로 여겨왔다. 하지만 이 책의
 
20. 사람들은 한 번에 4개 이상 기억하지 못한다
 
에 보면, 연구가 잘못되었다고 한다(Alan Baddeley, 1994). 새로운 연구(Baddeley 1996, Nelson Cowan 2001)에 따르면 7이 아니라 4라고 한다. 밀러의 7을 설명할 때도 전화번호 (예:555-1234) 였는데, 4를 증명할 때도 또 전화번호다.(예:555-1234)

필자의 마음속에 처음 든 생각은... "그래서... 또 속아야 하나?"하는 것이었다. UI를 설계하는 사람들이 기억해야할 것은, 사실 7이나 4 같은 숫자가 아니라, 사람들은 매우 적은 수만을 기억할 수 있다는 상식...과 실제 기억할 수 있는 숫자는 일반적 진리 보다는, 구체적 데이터에 의해 훨씬 더 좌우된다는 사실이 아닐까?


4. 이 책의 내용이 진실이라 하더라도, 그걸 그대로 UI에 적용하는 것은 잘못일 수도 있다는 사실을 기억하길.
만약 밀러의 7이 사실이라고 치자. 아니 새로 발견한 4가 진실이라고 치자. 이 책에서 제시하는대로 "각 정보 덩어리에 속한 하위 항목의 개수가 4를 넘지 않게(p50)" 해야 할까? 웃기는 일이라고 생각한다.

밀러의 7 이라는 숫자를 메뉴에 적용하려던 모든 시도는 의미없는 것으로 결론났다. 사람들이 쉽게 사용할 수 있는 최적의 메뉴 개수에 대해 많은 연구들이 일관되게 낸 결론은, 숫자는 의미가 없다는 것이다. 오히려 심포지움에서 발표했듯이(혁신적인 UI를 위하여 하지 말아야 할 7가지) 최적의 매뉴 개수라는 건 가장 덜 중요한 부분일 수도 있다. 이런 숫자에 연연하기 보단 그 의미에, 그리고 그 의미 보단 자기가 하려는 것에 더 집중하는 것이 필요하다.

이 책은 모든 사람들이 읽고 '상식 사전'처럼 활용하면 좋겠다. 물론, 자주 틀리는 것이 '상식'이고, 자주 실패하는 것이 '상식적인 디자인'이다. 그러나 몰상식이 되지 않기 위해선, 꼭 읽어야 한다.

참고
역자 소개글:http://uxfactory.com/913
저자 소개글:http://www.uxmag.com/articles/100-things-every-designer-needs-to-know-about-people

저자 블로그:http://www.theteamw.com/blog/


2010/05/30 - The Psychologist’s View of UX Design by 수잔 웨인쉔크

[참고##UI법칙##]


팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 1 Comment 0
Ad Test...
2010.04.13 02:08

윈도우 7 fitts's law 적용 실패 사례

http://en.wikipedia.org/wiki/Fitts's_law
마우스 같은 포인팅 디바이스로 대상을 선택하는데 걸리는 시간은 거리와 크기로 모델링할 수 있다. 대상이 가깝고 크면 빨리 선택할 수 있다.=쉽다. 

1. 유튜브가 화면을 아무데나 클릭하면 play/pause 하도록 하였습니다. 너무 편해졌습니다.

2. fitts's law에 대해 설명하는 책에는 항상 스크린상단에 붙어있는 macos의 메뉴바와 창마다 붙어있는 윈도우즈의 메뉴바를 비교합니다. 맥에서는 대충 커서를 스크린 위로만 밀기만하면 메뉴바가 선택됩니다. 선택 영역이 커지는 셈이 되어 쉽다는거죠. 맞습니다.
http://www.xvsxp.com/interface/fittslaw.php
*원문 링크가 깨져서 archive.org에 저장된 페이지를 링크합니다. archive.org 링크

3. 오늘 윈도우 7을 사용하다가 태스크바에 "바탕화면 보이기" 가 없어서 한참 찾았습니다. 검색해서 알았는데 오른쪽 아래 구석에 마우스를 올리면 바탕화면이 보이더라구요. 화면의 가장자리에 있어서 맥오에스의 메뉴바를 응용한 디자인인것 같습니다. 
아주 쉽게 커서를 옮길 수 있을것 같은 기대와는 다르게 마우스를 오른쪽 아래로 끌려면 손목의 스트레스가 커서 짜증나려고 합니다. fitts's law를 수정해야겠네요. 손목의 운동방향도 고려해야겠습니다.


http://www.webdevelopersnotes.com/articles/show-desktop-missing.php


 [참고##UI법칙##]

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 0
Ad Test...