블로그를 옮겼습니다: [디자이너(기획자)가 체화된 인지 관점에서 배울 점 읽기]

저작자 표시
신고

다음달 22일(2009년 5월 22일 금)에 홍익대학교 디자인혁신센터(http://www.openux.co.kr)에서 게임 UX 포럼이 열릴 예정입니다. 가제는 “Game Userability & Playability(게임 사용성과 오락성)”입니다. 넥슨 로두마니 스튜디오의 정영석님, 게임해설가 김정민님, 게임평론가 박상우님, uxfactory.com의 황리건님 등이 각각 1시간 정도씩 주제 발표를 하시고 마지막에 1시간 정도 패널 토의가 진행될 것 같습니다.

저도 우연찮게 이 행사에 꼽사리를 끼게 되어서 주제 발표 및 패널 토의에 참여합니다. 어느 개발자분께서 저를 발표자로 추천하셨다고 하는데 아마도 게임회사(엔씨소프트 오픈마루 스튜디오)에 다니고 있고 블로그에 UX나 게임 관련 글들을 올리고 있기 때문이 아니었나 싶습니다.

게임 회사 소속이기는 하지만 현재 게임 개발 업무를 하고 있는 것도 아니고 과거에도 게임 UI/UX 관련한 실무 경험이 없으므로, 행사를 준비하시는 분께 미리 이런 사정을 말씀드리고 게임 업계 종사자가 아닌 UX 전문가 정도로 소개해주십사 부탁을 드린 후에 강연 요청을 수락하였습니다.

그래도 여전히 쟁쟁하신 분들과 함께 이런 행사에 참여하는 것이 조금 겁이 납니다. 그치만 나름대로 좋은 경험을 할 수 있는 기회라는 생각도 들고, 참여하겠다고 이미 수락도 했고, 며칠 전에 첫 미팅도 했으니… 이제 와서 무를 수는 없는 노릇이고(ㅎㅎ), 그렇다고 어설프게 잘 모르는 내용을 떠들수도 없어서 고민이 많았죠.

걍 마음 편하게 먹고 제가 제일 잘 이야기할 수 있는 주제를 찾아보았습니다.

그래서 대략 2시간의 장고(응?) 끝에 선택한 주제는:

  • 주제: 인간 경험(Human Experience)
  • 개요: 우리는 사용자 혹은 플레이어이기 이전에 인간입니다. 사용자 경험(UX)이나 플레이어 경험(PX)에 대한 고민을 하기에 앞서 인간 경험(HX - Human Experience)에 대한 고민이 선행되어야 하는 이유를 살펴보고, 인간 경험이라는 틀이 주는 장점을 이야기하고자 합니다.

입니다.

이제 주제를 정했으니 열심히 공부하고 준비하는 일만 남았군요.

신고

1. The Interaction Design of APIs

얼마 전에 “The Humane Interface”에 대해 언급하면서 모드 없는 인터페이스, 모드 없는 소스 코드에서 사용자 인터페이스(UI – User Interface)에 적용되는 원칙이 프로그래밍 인터페이스(API – Application Programming Interface)에도 적용되는 사례를 이야기 했었는데요, 오늘 이와 관련하여 재미있는 슬라이드를 보았습니다.

The Interaction Design Of APIs
View more presentations from Alex Payne.

트위터의 API 디자이너인 Alex Payne이(pass님이 알려주셔서 추가) Stanford HCI Group에서 발표한 “The Interaction Design of APIs” 라는 제목의 슬라이드입니다. 슬라이드 쪼가리(ㅎㅎ)만 보고 내용을 유추해서 이야기해보면:

  1. API를 설계할 때에도 HCI(Human-Computer Interaction)의 관점에서 생각할 필요가 있음
  2. 좋은 프로그래밍 인터페이스의 조건, 나쁜 프로그래밍 인터페이스 요소
  3. 마지막으로 좋은 API가 갖추어야 할 자질들(qualities)

2번 중 나쁜 API의 사례로 자바의 날짜 관련 클래스들(java.util.Calendar, java.util.Date)이 언급되고 있군요. 정말 공감이 됩니다 (그나마 예전에 비해 좋아졌죠. 초창기에 java.util.Date는 mutable 이었습니다. java.util.Calendar가 나오면서 Date는 value object 취급을 받게 되었으나, 아직도 예전의 흔적 – deprecated APIs - 이 남아 있습니다). 그밖에도 Mac OS의 Keychain Service(아마 키입력을 담당하는 API인 것 같아요. Mac은 전혀 몰라서 계정과 암호를 담당하는 부분이라고 합니다. 한날님 감사), Win32의 다이얼로그 관련 API(ㅎㅎ 어디 이것 뿐이겠어요) 등을 나쁜 API로 소개하고 있습니다.

3번과 관련해서는, “The Humane API”의 자질로 탐색 가능성(explorable), 예측 가능성(predictable), 일관성(consistent)을 꼽고 있습니다.

2. The Humane Interface

사실은 “The Humane Interface”에서도 프로그래밍 인터페이스에 대하여 살짝 언급하는 부분이 있죠(p60). 해당 부분 번역이 특히 엉망이라 대충 읽고 넘어 갔었는데 구글 책 검색을 통해 원문을 찾아 읽었습니다. 대충 요약하자면 모드(mode)가 있는 시스템의 경우, 클라이언트가 시스템에 연결된 후 현재의 상태를 알아내기 위한 추가적인 작업을 수행하여야만 한다는 단점이 존재하는 점을 지적하고 있습니다. (그런 의미에서 HTTP는 잘 설계된 프로토콜이라는 얘기 ㅋㅋ) 엑셀 등에 존재하는 매크로 기능에 대해서도 언급하고 있는데 이 부분은 다음 기회에.

앞에서 소개한 슬라이드도 그렇고, 이 책도 그렇고 주로 Published API의 관점에서 이야기를 하고 있지만 꼭 그렇게 한정지을 필요는 없습니다. 의존(dependency)의 자기유사성(self-similarity)에서 스케일에 따라 다양한 종류의 의존성이 나타나는데 이들이 서로 유사한 속성을 공유한다는 이야기를 한 적이 있는데, API 설계 또한 이것과 마찬가지로, 스케일에 따라 다양한 측면에서 유사성을 발견할 수 있습니다. 라이브러리를 설계하건, DSL을 고안하건, 프레임워크를 만들건 다를 바 없습니다. 그런거 안하고 그냥 코딩만 하는 경우라도 다를 바 없습니다. 함수 하나 만들고, 다른 함수에서 이 함수를 호출하는 간단한 코드에도 이미 인터렉션(두 함수 사이의)이 존재하니까요.

이 책에서 말하는 “좋은 인터페이스”의 장점 중 하나는 사용자들의 올바른 습관 형성을 도와준다는 것인데요, 이 또한 API나 라이브러리, 프레임워크에 그대로 적용되는 이야기 입니다. Rails 류의 프레임워크가 제공하는 “Convention over Configuration” 철학의 진짜 장점은 타자를 적게 치게 해주어서 블로그를 5분만에 만들게 해주는 따위의 것에 있다기 보다는 프레임워크를 쓰는 개발자가 루비라는 언어, 그리고 웹이라는 기술을 올바르게 활용하는 좋은 습관을 들이도록 도와준다는 점에 있다고 생각합니다. xUnit 류의 단위 테스트 프레임워크도 마찬가지이고요.

이런 도구나 프레임워크를 열심히 사용하다보면 어느 순간 습관이 바뀌어 있고, 그 후에는 이런걸 쓰건 안쓰건 자신이 예전과 다르게 코딩하고 있음을 발견하게 됩니다.

3. 설계(design)와 디자인(design)

이처럼, 화면 설계(UI Design)와 프로그램 설계(API Design) 사이에는 통하는 면이 많습니다. 최근에 Kent Beck이 쓴 “Design is beneficially relating elements”라는 글은 아마도 설계(design)를 염두에 두고 쓴 글이겠지만, 기획(design) 혹은 디자인(design) 관점에서 읽어도 큰 영감(과 감동)을 얻을 수 있습니다. 이에 대해서는 "디자인이란 서로를 이롭게 연결하는 것"을 참고해주세요

신고
The Humane Interface 3장에 이어 4장 스터디를 끝냈습니다. 4장의 주제는 정량화(quantification) 입니다. 키워드는 GOMS, 인터페이스 효율성, Fitts' Law, Hick's Law 입니다.


1. GOMS

GOMS는 Goals, Operators, Methods, and Selection rules의 약자로 사용자와 컴퓨터 사이에서 일어나는 인터랙션을 작은 단위들로 환원하기 위한 모델입니다. 이 책에서 저자는 단순화된 키보드입력 수준의 GOMS를 소개하고 있는데, 예를 들면:
마우스를 잡고 있던 손을 키보드 위로 옮기고(homing), 세자리 숫자를 입력한 후(keying, keying, keying), 엔터(keying)를 친다.
라는 일련의 동작은
HKKKK
로 표현됩니다. 근데 키보드 위로 옮긴 다음 숫자를 입력하기 전에 사용자가 "뭘 입력할지" 떠올리는 시간(mentally preparing)이 잠깐 필요하다면
HMKKKK
가 되겠죠.

이런 설명을 듣고 나면 전 항상 이런 궁금증이 생깁니다. 이렇게 환원해서 뭘 어쩔건데? 이거 왜 하지?

뭐 다양한 응용을 할 수 있겠지만 인터페이스의 효율성을 측정하고 개선하는 일에 응용할 수 있겠습니다. 예를 들어 keying은 0.2초, homing은 0.4초, m은 1.35초라고 하면, 위 인터페이스를 이용하여 작업을 완수하는데 걸리는 시간은
0.4 + 1.35 + 0.2 + 0.2 + 0.2 + 0.2
가 됩니다. 이런 식의 측정을 통해 화씨/섭씨 변환 UI의 효율성을 개선하는 사례를 소개하고 있습니다.


2. 인터페이스 효율성

저자는 인터페이스 효율성이라는 재미난 개념을 소개하고 있는데요, 쉽게 말하면 사용자가 인터페이스를 통해 컴퓨터에게 실제로 제공한 정보의 양이 컴퓨터가 과업을 수행하기 위해 필요한 정보의 양에 가까울수록 인터페이스의 효율성이 높다고 보겠다는 개념입니다. 전자가 후자에 비해 낮을 수는 없으므로 효율성은 0 에서 1 사이의 값을 갖습니다.

뭐 열역상에서의 효율성이나 정보이론에서의 효율성과 다르지 않은 개념입니다만, 이걸 인터페이스에 이렇게 적용한다는 시각이 재미난거죠. 정보이론의 전통을 따라 인터페이스가 필요로하는 정보량은 비트(bit) 단위로 계산합니다. n가지 선택사항 중 한가지를 고르는 문제가 요구하는 정보량은
log2n
이 됩니다. 설명을 읽어보니 사용자가 화면을 보며 이진검색(binary search)을 한다고 가정한 모양입니다. 그 가정이 맞건 안맞건 이 모델이 예측하는 바가 실제 실험 결과와 유사하다고 하니 저 같은 사람은 그냥 그런갑다 하고 넘어가면 되겠습니다. ㅎㅎ

여기까지 읽으면 또 아까랑 비슷한 의문이 생기죠. 인터페이스의 정보량 왜 측정하는데?

이게 인터페이스가 달성할 수 있는 효율성의 이론적 하한선을 규정해주기 때문입니다. 즉, 언제 디자인에 대한 투자를 멈춰도 좋은지에 대한 쓸만한 판단 기준이 된다는 얘기죠. 이렇게 써놓고 보니, 저자의 아들이 2년 전에 썼던 글 "Know when to stop designing, quantitatively"이 생각납니다. 아버지와 달리 그림도 좀 넣어주고 설명도 좀 친절하단 말이죠 ㅎㅎㅎ


3. Fitts' Law

Fitts' Law는 쉽게 말해서 클릭하기 좋게 만들려면
  • 버튼 크기를 키우던가,
  • 버튼을 화면 구석(변이나 모서리)에 놓던가,
  • 마우스 이동 거리를 짧게 만들던가.
하라는 얘기입니다.

버튼 크기를 키우자는 얘기는 뻔한거라 생략하고, 버튼을 화면 구석에 놓은 사례는 MacOS의 메뉴(항상 화면 상단에 있습니다), MacOS의 Dock(항상 화면 하단 혹은 측면에 있습니다) 등을 떠올리시면 됩니다. 윈도XP의 시작메뉴는 예전 글에서 설명한 이유로 인해 매우 부적절한 사례입니다.

마우스 이동 거리를 짧게 만든 사례는 마우스 우클릭을 하면 버튼 바로 옆에 나타나는 컨텍스트 메뉴, 오피스 2007에 추가된 미니툴바 등을 들 수 있겠습니다:

참고로, Fitts' Law는 수식으로 쓰자면 아래와 같습니다:
a + b log2(D/S + 1)
a,b는 대상 환경에 따라 실험적으로 정해야하는 변수이고 D는 이동거리, S는 버튼의 크기입니다. 여기에도 log가 나오는군요.


4. Hick's Law

Hick's Law는 화면에서 뭘 고르려고 할 때 요소가 많아지만 많이질수록 시간이 늘어난다는 법칙입니다. 에 근데, 그냥 늘어나는게 아니라 base를 2로 하는 log 함수에 따른다는 얘기. 식으로 만들면 Fitt's Law랑 똑같다죠:
a + b log2(n + 1)
이렇게 적어놓고 보면 재미난 함의들이 몇 가지 보입니다. 그 중 하나를 책에서 인용하자면:
하나의 메뉴에서 8개의 선택 항목 중 하나를 선택하는 것이 2개의 메뉴에서 4개의 항목 중 하나를 선택하는 것 보다 빠르다.
라는 것입니다. 과연 그럴까 싶지만 통제된 상황에서 측정해보면 그렇다고 합니다.


5. 결론 혹은 저자가 강조하고자 하는 바

결론은 1) UI의 많은 요소가 정량화 가능하다. 2) 실제로 정량화/측정을 하건 안하건 각 법칙이 갖는 함의들을 체화하여 모든 디자인 과정에서 적절히 녹여내는 것이 중요하다. 입니다. (재미난 점 하나. 이 글 2, 3, 4번 섹션에 각각 수식이 하나씩 나오는데 전부 똑같이 생겼습니다. --; 세상은 로그라능 ㅋ)

PS: 아니 그러고보니, 오늘은 대머리장군님이랑 규하횽아랑 시비가 붙었던 시비시비로군요.

신고
Jef Raskin의 "인간 중심 인터페이스(The Humane Interface)"로 팀 동료들(웹클라이언트 개발자들)과 함께 스터디를 하고 있습니다.

참 훌륭한 책이죠.

그런데 읽다보니 앞뒤가 안맞는 것 같은 문장도 있고 오역인듯한 문장도 있고 해서 네 페이지 정도를 원문과 대조해봤습니다. 한 10분 살펴봤는데 오역과 빠진 문장들이 눈에 띄네요. 쩝쩝. 아쉽습니다.

32페이지, "주의 소재의 단일성" 중 번역을 안하고 빼먹은 문장:
Common parlance recognizes this observation. For example, we may have a thought, and we may have many thoughts, but we speak of our attention only in the singular. We never speak of a person's attentions except in unrelated usages, such as unwanted attentions.
34페이지, 오역:
번역: 컴퓨터 작업은 어려울 뿐 아니라 스트레스를 많이 주기 때문에 사용자들이 컴퓨터 시스템과 씨름 하느라 과업을 제대로 마치는 것을 등한시 하기도 한다.

원문: The use of a computer is often so stressful and difficult that a user will become absorbed in working on the computer system, and therefore distracted (빗나간, 마음이 산란한;미친 듯한) from the completion of tasks.

* 사용자가 등한시하는 것이 아니라 어려운 인터페이스 때문에 과업에 집중하지 못한다는 얘기입니다.
또 34 페이지 오역2:
번역: 인터페이스 디자이너들은 사용자의 주의 소재가 커서이고 따라서 커서의 모양만 바꾸어 주면 사용자의 주의를 끌어낼 수 있으리라고 생각한다. 커서의 위치는 표시하기에 용이한 것이기는 하지만 그러한 표시가 눈에 띄지 않을 수도 있다. 커서의 모양 자체는 주의 소재가 아니다. 그 커서가 가르키는 지점이 바로 주의 소재이다.

원문: For example, interface designers sometimes assume that the user's locus of attention is the cursor and that changing the cursor's shape will inevitably command the user's attention. The cursor location is a good place to indicators, but even there, the indicator can go unnoticed; the shape of the cursor is not the locus of attention; rather, the place or object to which it is pointing may well be.

수정: 예를 들어, 인터페이스 디자이너들은 종종 사용자의 주의 소재가 커서이고, 커서의 모양을 바꿔주면 틀림없이 사용자의 주의를 끌 수 있으리라 생각한다. 커서의 위치가 비록 식별자를 표시하기에 적절한 곳이기는 하지만, 그럼에도 불구하고 사용자가 식별자를 눈치채지 못할 수 있다. 커서가 지칭하고 있는 위치나 대상이 주의 소재일 수 있는 있으나, 커서의 모양 자체는 주의 소재가 아니다.
음냐. 지난주에 산 책인데 2003년 2월 버전 초판이군요. 재판 찍을 때 오역들이 좀 정정되면 좋겠습니다. 좋은 책인데.

신고
< Newer     Older >

티스토리 툴바