아랑이의 유아이랑

혹시 이것에 대해서 생각해보신 적 있으신가요? | 토론장  2004/07/01 11:49
 
락필(deathrock)   http://cafe.naver.com/ux/528
 
[질문 요약] 
게시판 목록 번호가 있거나, 게시판이 번호가 없을 때,

이전글은 어느것?
다음글은 어느것?

이전글은 윗글에 해당? 아랫글에 해당?
다음글은 윗글에 해당? 아랫글에 해당?

======================================================================================

이전/다음 버튼은 화살표와 함께 씁시다.

일단 이 문제는 상당히 많은 사람들이 고민하였으나, 최근에는 어느 정도 암묵적인 합의하에 다음과 같이 결론이 났다고 봅니다. (저는 이 방법이 최선이라고 생각하지는 않습니다만.)

결론은 아래 그림과 같이 '이전' 혹은 '다음' 메뉴에 위/아래 화살표를 병기하는 것입니다.

그렇다면 이것이 왜 지금까지의 결론이고 왜 최선이 아닌지에 대해서 제 생각을 말해 보겠습니다.

----------------------

먼저 왜 게시판에 번호가 있는지 한 번 생각해 봐 주기 바랍니다.

게시물의 번호는 인간에게 어떤 정보를 주나요? 키보드로 입력하여 게시물을 선택하는 시스템이 아니라면 (즉 예전 PC 통신 시절이나 모바일 같은 화면이 아니라면) 게시물의 번호는 인간에게 별 도움이 안됩니다.

게시물의 번호는 일종의 menu 시스템이었습니다. 이 메뉴 시스템의 가장 큰 특징은 입력(번호)과 출력(게시 내용)을 분리하였다는 것이죠. (Menu decouples the functions of input and display, from Menu-driven Systems by Lee & Raymond, 1993)

또한 프로그래머에게 게시물 번호는 데이터베이스를 정리하는데 있어서 가장 중요한 인덱스이기도 했죠. 그리고 사람들 사이에서도 "야, 어디 게시판 들어가서 2120번 게시물 읽어봐. 그것 때문에 난리났어"라고 할 정도로 기억되는 효과도 있었구요.

그러나 키보드 보다는 마우스로 직접 클릭하는 것이 더 익숙한 시스템이 되면서 게시판 번호는 이제 의미를 잃어가고 있는 중입니다. 여전히 나온다면 (위에서 말한 예외적 상황을 제외한다면) 대부분 별 생각없는 기획자의 습관이거나, DB oriented된 개발자의 강압이겠죠.

그런 폐해는 이 네이버 카페 게시판의 게시판 번호를 보면 잘 나타납니다.

(네이버 카페는 정말 잘 만들어 졌습니다. 누군지 한 번 만나보고 싶지만) 단지 게시판 번호 부분만 보면, 게시판 번호는 게시판의 종류를 가리지 않고 한 가지로만 생성이 되다 보니까 (게시판 간에 게시물을 자유로이 옮기려면 db는 하나만 있어야 겠죠?) 어느 한 게시판에 들어가서 게시물 번호를 보면 '흠... 게시물 번호가 도대체 무슨 의미가 있는거지?' 라는 생각을 극명하게 들게 하죠.

하여간 게시물 번호를 없애 본다면, 어떻게 되냐면 아웃룩 익스프레스에 메일 목록처럼 될 겁니다. 아니면 주소록 처럼 될 수도 있고요.

이 상태에서 아웃룩은 편지가 온 순서, 보낸 사람 이름 순, 편지 제목 순 등으로 다양하게 정렬(sorting)할 수 있습니다. 더욱 중요한 것은 이 모든 순서의 역순도 가능하기 때문에 더 이상 '이전'이나 '다음'에 무언가 뜻을 부여한다는 시도가 허망한 것입니다. 따라서, 우리는 A 버튼과 B 버튼이 필요한데,

A : 현재 게시물들이 정렬되어 있는 상태(시간이든, 다른 무엇이든, 아님 그것의 역순이든)에서 시각적으로 그 게시물 윗쪽 혹은 왼쪽에 있는 것 보기

B : 현재 게시물들이 정렬되어 있는 상태(시간이든, 다른 무엇이든, 아님 그것의 역순이든)에서 시각적으로 그 게시물 아랫쪽 혹은 오른쪽에 있는 것 보기

그렇다면 A와 B는 어떻게 디자인 되어야 할 까요? 먼저 위쪽 아랫쪽 화살표가 들어간다면 의미가 분명해 지겠죠. 그리고 레이블링은 어떻게 할까요? '위'  or  '위 게시물'  or  '위 게시물 보기' 등 주어진 상황과 워칙, 가이드에서 여러 개를 생각해 볼 수 있겠죠. 그런데 레이블링을 할 때 대부분의 경우 짧게 하려고 하니까,

잠정 결론 1: 위쪽 화살표와 함께 '위' 라고 레이블링 한다.

위의 결론을 채용한 경우도 본 적이 있는데, 이렇게 하면 의미상의 혼란이 생깁니다. 무얼 위로 올린다는 것인가? 즉, 위에 있는 것을 보는 게 아니라, 지금 보고 있는 것을 위로 올리는 것과 헷갈리는 거죠.

잠정 결론 2: 위쪽 화살표와 함께 '이전'이라고 레이블링 한다.

화살표와 이전은 서로 앞뒤가 안 맞긴 하지만, 화살표는 진정한 의미를, '이전'은 다른 곳에서 사용하는 익숙한 레이블을 가져와서 하려는 기능을 암시하여 표시하는 것입니다.

다리가 한 쪽씩 밖에 없는 두 사람이 어깨 동무하고 간신히 서 있는 상태랄까요?

하여간 현재 업계는 여기에서 만족하고 정착한 듯이 보입니다.

누군가 좀 더 명확한 그림과 레이블링을 만들어 의미를 두 배로 강화시키는 것을 만들 때까지 말이죠.

---------------------------------------------

게시판 숫자가 사람에게 전혀 효용이 없다고 했는데, 사내 토론에서 몇 가지 효용이 생각났다.

1. 게시판의 크기를 보여준다. 숫자가 20이냐 20000이냐에 따라 게시판이 얼마나 오래 되었는지, 혹은 얼마나 많은 사람들이 게시판에 글을 쓰는지 등을 알 수 있는 척도가 되는 것이다. 음식점에 들어가기 전에 살짝 들여다 봐서 점심시간인데 손님이 하나도 없으면 들어가기 불안해지는 것 처럼, 게시판의 숫자는 이런 척도가 될 수 있을 것 같다. (물론 게시판 개발자들이 좀 더 정확한 social activity indicator를 만들어 주길 7년전부터 기다리고 있다. 그걸 알면서 왜 안 만들고 있느냐고? 흠...)

2. 시각적인 bullet이 될 수 있다. 불릿의 효용은 수직적 안구 운동의 연결점이자 수평적 안구 운동의 '닻'이다

3. 개발자들에게 심리적 안정감을 주고, 개발팀 전체에 '평화'를 준다. 괜한 고집으로 불란 일으키지 말고 조용히 하던대로 하자. UI 개발 원칙 중 중요한 것이 있다면, 그건 '남들 하는대로 하라'일 것이다.

이상의 효용이 중요하다고 할 수도 있고, 안 중요하다고 할 수도 있겠다. 상황에 따라 다를 것이다. 또한 특정 상황에서만 중요하다고 생각한다면, 네이버 카페 게시판처럼, 게시판 형태에서만 보여지고, 블로그 형태나 웹진 형태에서는 사라져 버리도록 만들 수도 있을 것이다.

=================================================================

pxd에서 초급 UI 디자이너를 모집합니다. 아래 참고 바랍니다.

http://cafe.naver.com/ux/475

2004/4/10

진화론자인 나는 신을 믿지 않지만 누군가 이 세상을 창조한 설계자가 있다고 상상하는 것은 재미난 일이다.  

간혹 회사 직원들과 각종 먹거리의 UI를 토론해 보기도 하는데, 예를 들어 ‘게’ 같은 경우는 너무 맛있는데 왜 그렇게 먹기 힘들게 만들어졌을까? 한 번에 먹기 적당한 크기로 포장되어 있고, 그 안에 두 가지 다른 맛이 들어있는데다가 영양소도 풍부하다니 ‘달걀’ 같은 것이 가장 좋은 것 아닐까? 더군다나 운반/보관을 위하여 세로 방향은 강하게 만들어 졌고, 요리를 한 손으로 할 정도로 간편하게 하기 위하여 가로 방향은 약하게 만들어졌다. 그러나 일반적인 먹거리는 설계자가 처음 설계할 때 본연의 목적이 ‘먹히는 데’ 있지 않기 때문에 토론이 진지해 지기는 힘들다. 그런데 유독 과일은 일단 동물에게 ‘먹힘’으로서 자신의 가치를 발휘하는 것이므로 더욱 치열한 논의를 할 수 있는데, 본질 가치인 ‘맛’과 ‘영양’이 가장 중요한 부분인 것은 말할 것도 없지만, 여기는 UI에 관한 것이므로 과일들을 UI 측면에서 살펴 보는 것도 재미있을 수 있겠다. 사람에게 쉽게 먹힐 수 있는 UI 를 갖고 있는 과일은 무엇인가?

이 때 주의해야 할 것은, UI 를 UI 자체로 보지말고, 좀 더 넓은 Context, 혹은 사회적 환경에서 봐야 한다는 점이다.

원시 시대를 상상해 보면 아무래도 사과 같은 과일이 가장 좋은 인터페이스를 가지고 있지 않나 생각한다. 벗길 필요도 없고, 씻을 필요도 없이 나무에서 따서 바로 한 입 베어 물면 입안 가득 퍼지는 사과향… 아마 성서에도 그런 이유로 사과가 등장한 것이 아닐까?

아예 껍질이 존재하지 않는 딸기도 마찬가지이나, 메추리알과 딸기 같은 정도 크기의 먹거리들은 항상 먹기 위한 수고에 비해 한 번에 먹을 수 있는 양이 너무 적기 때문에 효율이 떨어진다는 단점이 있다. 사과하나를 따는 노력이나 딸기 하나를 따는 노력이나 비슷한데, 사과는 따고 나면 간단한 간식 정도는 되니까 말이다. 더군다나 딸기는 운반 도중 망가지는 경우도 흔하다. 껍질이 없기 때문이다.

얇은 껍질의 감도 마찬가지. 특히 홍시 같은 경우나 참외 같이 껍질 안의 것이 줄줄 흘러 내리는 경우… 도구 없이 먹다간 품위를 잃는다.

그러나 오늘날 각종 공해와 농약의 우려가 넘치는 시대 환경에서 껍질째 혹은 껍질 없이 먹는다는 것은 별로 매력적이지 못 하다. 따라서 어느 정도 두꺼운 껍질이 존재해야 유리하다고 생각한다.

그런데 수박이나 메론 같은 경우 껍질이 너무 튼튼하다 보니 매우 강력한 ‘힘’이나 ‘칼’ 같은 도구가 없이는 먹기가 힘들다. 튼튼한 껍질은 운반에서 용이하지만 반대로 먹기 불편한 결과를 낳는 것이다. 더군다나 수박은 한 덩이의 크기가 너무 커서 핵가족화한 현대 사회에서는 한 가족 조차도 한 번에 한 덩이를 소화하기 힘들다.

벗기기 쉬운 껍질을 가진 것으로는 바나나가 있다. 바나나는 노란색으로 길죽한 모양을 가지고 있어 작은 입을 가진 사람도 적당량씩 먹을 수 있게 편리하게 설계 되어 있다. 또한 껍질의 색이 파란색 -> 노란 색 -> 검은 점 무늬 등으로 익은 상태에 따라 변하는 인디케이터 역할을 하고 있는데 이것은 특허 출원 감이다. (하이트 맥주 캔에 가장 맛있는 온도를 표시하는 부분도 특허다) 한 쪽은 뭉툭하지만, 다른 한 쪽은 ‘꼬다리’가 있어서 여러 가지 용도로 활용된다. 꼬다리 부분부터 껍질을 벗기는 사람은 이 꼬다리를 Opener로 활용하는 사람이고, 반대쪽부터 껍질을 벗기는 사람은 이 꼬다리를 손잡이(Handle)로 활용하는 경우이다. 물론 Opener로 쓰고 나면 나중에 끝부분을 쥐기가 좀 불편하고, Handle로 활용할라 치면 처음 껍질을 까기 시작할 때 다소 불편하다. 유학시절 지도 교수 포함 학생들과 이 문제로 우연히 잡담하던 적이 있었는데 대부분 Opener로 사용하고 있어서 Handle로 사용하는 나로서는 좀 놀란 적이 있다. 당신이 조물주였다면 이 꼬다리는 Opener로 설계했을 것 같은가? 아니면 Handle로 설계했을 것 같은가?

오렌지는 바깥 포장 안에 개별 포장이 되어 있어 먹다가 잠시 중단할 수도 있다. 전체를 까지 않고 반만 깐 다음 반을 먹기도 좋다. (물론 맨 겉쪽은 약간 마르긴 하지만) 가장 좋은 경우는 두 사람이 나누어 먹을 때, 개별 포장이 되어 있기 때문에 별도의 도구 없이 쉽게 즐길 수 있다. 바나나의 경우 혼자서 조금씩 나눠 먹기는 좋아도 둘이 나눠 먹기는 불편하다. 바나나 하나를 나눠 먹어본 경험이 있는 사람은 누구나 기억할 것이다. 껍질을 까지 않은채 뭉개어 나눠야 하는 불편함을…

그런데 오렌지의 껍질은 손으로 쉽게 까기에는 약간 두꺼운 감이 있다. 그래서 내가 뽑은 최고의 과일은 귤. 물론 맛을 제외하고 인터페이스 측면에서다. 일단 상품을 보호하는 껍질 – 까기 쉽고, 조금만 익숙해 지면 상품 내부의 상태 (익었는지, 상했는지)를 그럭저럭 알 수 있고, 또한 내부에 개별 포장 되어 있어서 시간을 두고 나눠 먹기나, 동료와 나눠 먹기 편하다. 물론 과대 포장이라는 비난이 있을 수 있으나, 먹을 수 있는 포장이라는 면에서 용서가 된다. 속포장재가 약간 맛을 떨어뜨리는 단점이 있긴 하지만 크게 신경 쓸 정도는 아니다. 오히려 개선해야 한다면 속포장재에 달라 붙는 겉포장재의 잔재 – 흰 줄무늬를 좀 없도록 하면 좋겠다. 물론 심심할 떄 그것을 뜯어내 가며 먹는 재미는 있지만서도.

당신이 생각하는 ‘먹기 쉬운’ 과일은?

불편하게 만들자 1 (2004-6-10)

많은 User Interface Designer들이 ‘편리하게’ 만드는 것에만 집중하고, 불편하게 만드는 것에는 신경을 쓰지 않는다. 오늘은 그것에 대해 이야기해 보려 한다.

초보 사용성 전문가들과 이야기를 나누다 보면, ‘쓰기 편하게’ 만들어야 한다는 구호에 너무 고취된 나머지, 자신들이 사용하기에 조금만 불편하다 싶으면, 잘못 디자인되었다고 투덜거린다. 그것은 이러이러한 이유로 그렇게 디자인된 것이라는 설명을 들어도, 심지어 어떤 사람들은 ‘사용자’에게 맞추지 않았다고 불평한다.

예를 들어 문 손잡이를 생각해 보자. 문 손잡이는 당연히 문이 어떻게 열릴 것인가(밀어야 열리는지, 당겨야 열리는지, 미닫이인지, 자동인지, 수동인지 등)에 대한 직관적인 암시를 포함하고 있어야 한다. 그렇지 않으면 사람들은 밀어야 될 문을 당겨 보는 등 수고를 피할 수 없기 때문이다. 자꾸 반복되는 실수 앞에서 건물 주인은 “미시오” 혹은 “당기세요” 등의 문구를 커다랗게 써서 붙일 수 밖에 없게 된다.

물론 여건이 허락된다면야 어느 방향에서든 밀어서 열리는 문이 보통의 경우에는 편할지 모른다. 그러나 그러한 여건이 되는 상황도 드물고, 그에 따른 재료비도 생각을 해야 하므로 언제나 그렇게 만드는 것이 최선은 아니다.

그런데 예전에 우연한 기회로 은행에 동행했던 한 사용성 전문가는 은행에서 자기가 생각했던 방향으로 문이 열리지 않는다고 불평하였다. 바깥으로 나가려는데 항상 문을 당겨야만 한다는 것이다. 많은 사람들이 이 문제 때문에 불편해 하고 있었다. 들어오기는 쉬운데 나가기는 불편하다.
그러나 내 생각에 은행 문은 나가기가 조금은 불편해야 한다. 순간적으로 돈을 낚아채 튀는 소매치기를 순발력 느린 청원 경찰이 잡을 수 있는 기회도 그 뿐이다. 흉기로 위협하고 챙긴 현금 다발을 놓칠 수 있는 기회도 뜻대로 쉽게 열리지 않는 이 문 때문일 수 있다. 실제로 손실(평상시 사람들이 겪는 불편)과 이익(비상시 확보될 수 있는 안전)을 빈도와 가중치로 비교했을 때 과연 이렇게 만드는 것이 적절하냐는 것은 구체적인 데이터를 가지고 판단할 일이다.

내가 하려는 이야기는 소위 사용성 전문가를 자처하는 초보자들이 조금만 불편하거나 자기가 알고 있는 원칙에 어긋나면 쉽게 빨간 지시선을 쭉 빼내어 불편하다고 파워포인트를 만드는 우리(나 자신 포함)를 되돌아 보자는 것이다. 그것을 개발한 사람의 깊은 속은 알지도 못 한채…

(계속)

지난 번 인터랙션지(2004 JAN+FEB)에 재미있는 기사가 많았는데, 그 중 innovation에 관한 두 기사("To Innovate or Not to Innovate"와 "Digging in the Wroing Spot")가 특히 그랬다.

User-centered Design (UCD)를 하는 사람들이 흔히 조심해야 하는 것으로 바퀴 다시 발명하기(reinvening the wheel)가 있는데, 이는 새로운 것을 찾다 보면, 이미 남들이 다 고려했던 것을 다시 생각하구선 좋아하는 결과가 되는 것을 경계함이다. 웬만하면 현재 것을 쓰는 것이 안전한 UCD의 세계에서 혁신이란 무엇일까?

첫 글에서 저자는 2003년도 미국 기업 임원들을 대상으로 한 혁신에 대한 조사를 인용하였는데, 23%가 혁신을 'a solution that identifies and addresses the unmet needs of consumers'이라 하였으며, 이것을 'discovery'나 'revolution'과 연관시킨 사람은 매우 드물다고 한다. 또한 조사 대상자 절반 이상의 임원들이 불경기에도 불구하고 innovation과 관련된 예산을 증액했다고 말하고 있다. 이를 달성하기 위한 다양한 기법으로서 관찰, 프로파일링, 평가 등을 글에서 열거하였다.

두 번째 글의 저자는 잘못된 문제를 해결하려고 애를 쓰다가 낭패를 보는 경우가 많다고 하면서, "redefine the problem"이 중요하다고 한다. 저자가 직접 말하진 않았지만, 나는 읽으면서 바로 이것이 혁신의 핵심이라고 느꼈다. 내가 지난 10년간 이 분야의 일을 하면서 해냈던 많은 '혁신'의 핵심은 알려진 문제의 'solution'을 찾은 것이라고 보다는 위의 글대로 알려지지 않은 문제의 solution, 혹은 다른 말로 하면 'redefine the problem'을 함으로써 얻은 것들이다.

두 가지 글을 읽으면서 내 머리에 떠오르는 생각은 혁신과 사용성에 관한 내 오랜 불만이었다.

논리적으로는 그렇지 않음에도 불구하고 현실에서는 Usability, Standard, Guideline 옹호자들은 대개 innovation의 적이다. 그것은 사람의 사고 과정이 한정되어 있음을 고려하면 어쩔 수 없는 일이라 여겨진다.

흔히 이 분야의 초심자들이 쉽게 저지르는 오류가, 사용자 중심- 하면 '사용성 평가'부터 떠올린다는 것이다. 아무래도 쉽게 이해하고 중요한 개념이다 보니 그렇기도 하겠지만, 담박에 결과가 들어나야 좋아하는 업계의 풍토와, 정량적 데이터가 들어나야 '연구 결과'가 되는 학계의 풍토가 동시에 빚어낸 것이리라 생각한다. 나도 처음 시작할 때, '사용성 평가'가 전부 다 인 줄 알았고, 또 '사용성 테스트룸(One-way Mirror Room)'이 전부 다 인줄 알았더랬다. 다행인 것은 나만 그러는게 아니라, 그 뒤에 다른 사람들 (한국/미국 모두) 보니, 다들 처음 시작할 때는, 사용성 사용성 하면서 일단 테스트 룸 부터 갖추고 이를 업적으로 자랑하는 여러 회사를 볼 수 있었다. 또한 아무리 설득해도 끊임없이 정량적 자료를 요구하는 고객도 여럿 있었더랬다.

그러나 정작 '평가'라는 것은 무언가 '기준'이 서지 않고는 안되는 일이고, 이 '기준'이 잘못되면 모든 것이 의미없는 것이 될 수도 있는 일이다. 또한 속성상, 창조의 고통을 이해하기 보다는 비현실적 이상에 기초하여 깍아내리기 좋아하는 문단의 평론가들처럼 공허한 입방아만 늘어놓기 십상이다. 이런 편향된 방법이 고객을 실망시키고... UI ? 해 보니 별거 안 나오데? 라는 선입관을 갖는 고객만 늘어나게 될 수 있다. UI 원칙들이라는게 양면적이고 상호 모순적인 것들로 가득차 있는 관계로 이를 근거로 평가하면 이어령비어령 식의 결과가 나오든지 하나마나한 뻔한 이야기가 나오게 되기 쉽기 때문이다.

물론 제대로된 평가는 중요하고 의미가 있으나 전반적 시장의 상황은 긍정적 지향점보다는 부정적 결과에 더 주목하고 있는 형편이다. 이에 대해 나 자신도 실망하고, 이 분야를 때려치워야 겠다고 생각할 때 쯤 내 사고를 전환시킨 계기가 있었는데, 이 분야에 '사용성 평가'만 있는 것이 아니라, 수많은 '창조'의 방법도 있더라는 것이다... 그 전에는 없던 것이 새로 나타난게 아니라, 뒤섞여 있던 것이 어느 날 부터 내 눈에 구분되어 보여지게 되었다는 이야기다. 그리고 세상을 다시 보니, 이미 많은 사람들이 이러한 해악을 눈치챈 모양이었다. 최근 읽은 다양한 영문 기사/책에서 이러한 분리를 시도하는 것을 보았다. 그 중 하나가 위의 첫번째 기사이고, 또 contextual design 책이 그 둘이고, ok-cancel의 만화들이 그 셋이다. 이들 모두 조심스럽게 User Interface에서 '평가' 혹은 '평가자'와 '창조' 혹은 '설계자'를 구분하려고 하고 있다.

다른 적용이 있을 수도 있겠으나, 전반적으로 산업 공학과 연관된 '사용자 평가'의 작업들은 모두 후행 평가다. 여기서 혁신적인 것이 나올 수도 있겠으나, 그 보다는 선행적인 '사용자 연구'에 의해 더 쉽게 가능하다고 생각한다. 이를 위해 우리 회사에서 사용하고 있는 다양한 연구 기법들 (각종 Inquiry or observation기법, 각종 user profiling or modeling 기법, 각종 prototyping 기법, 각종 논리*창조 기법 등등)이 '평가' 기반 보다는 확연히 구분되는 innovation 기법이다. (여기서 '후행'이란 말은 시간적으로 뒤에 벌어진다기 보단, 기준이 먼저 만들어진 뒤 실행하는 평가의 속성상 새롭게 문제를 정의하기 보단 이미 정의된 문제에 근거한다는 뜻이다.)

딱 부러지게 구분은 안되지만, 그래도 사용자 인터페이스 업계에, '평가' 기법과 '창조' 기법은 구분되어야 한다고 생각한다.

또한 여기에 추가하여 한 가지를 더 하자면 '생산' 기법이다. 최근 몇 년새에 상당한 인기를 끌고 있는 pattern approach의 경우 또 하나의 '표준화'로 접근하게 되면 innovation의 적이 될 것이다. 이것은 UI의 '생산성 향상'으로 초점을 맞춰야 하고 다행히 그렇게 되고 있다.