아랑이의 유아이랑

혹시 이것에 대해서 생각해보신 적 있으신가요? | 토론장  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의 '생산성 향상'으로 초점을 맞춰야 하고 다행히 그렇게 되고 있다.

얼마전 HCI연구회 게시판에 올렸던 글인데, 여기 분들도 관심 있으실 것 같아서 약간 수정하여 올려 봅니다.

컨펌 메시지와 소프트웨어의 자신감

> 아웃룩으로 메일 보낼 때
> 메일을 보내시겠습니까? 를 왜 안물어보고
> 확~ 보내는지 아는 분 있나요?
>

일단 제 간단한 생각은... 물어볼 필요가 없기 때문이라는 것이 제 생각입니다. 흠... 다시 질문을 바꾸어 보면... 왜 물어봐야 하죠?

일반적으로 Confirm 메시지를 보여주는 가장 좋은 규칙은, 되돌릴 수 있는 것이면 묻지 마라는 거죠. 예를 들어 파일 삭제의 경우, 휴지통에 들어가서 다시 살릴 수 있는 상황이면 '정말 지우겠냐'라고 묻지 말고, 파일 삭제후 복구가 안되는 상황이라면, '정말 지우겠냐'라고 물어야 한다는 겁니다.

그러나 모든 UI Design의 원칙들이 그러하듯이 여기에는 '원칙'자체를 무의미하게 만드는 수많은 크고 작은 예외들이 존재하는데, 예를 들어, 키보드 시퀀스상 실수로 쉽게 삭제키가 눌려질 수 있는 상황이라든지, 달리 변경할 수 없는 애매한 아이콘이나 버튼 레이블 때문에 호기심에 찬 사용자가 자주 눌러 볼 수 밖에 없도록 만들어진 삭제 버튼을 피할 수 없는 상황이라든지 하는 경우라면 되돌리기 가능해도 컨펌 메시지를 넣는 것이 좋겠죠.

윈도즈 시스템에서 드래그 앤 드롭으로 휴지통에 떨어뜨리면 묻지 않지만, 파일 선택 후, Delete키를 눌러서 삭제할 경우에는 컨펌을 받습니다. 아마도 삭제키는 실수로 눌려지기 쉽지만, 실수로 휴지통에 떨어뜨리기는 어렵다고 생각했기 때문이겠죠. (물론 저도 실수로 휴지통에 떨어뜨린 경험이 있지만 그건 너무 예외적인 경우겠죠)

반대로 지워질 대상 자체가 썩 그리 중요하지 않은 것이고 작업의 효율성이나 속도가 중요한 경우, 이미 해당 작업 자체에 안전장치가 있는 경우 (예를 들면 동시에 눌릴 수 없는 복잡한 키 조합을 할당한 경우) 라면 지워진 후 되돌릴 수 없다 하더라도, 컨펌 메시지를 보내지 않는 것이 좋겠죠.

특히 사용자 작업 순서상, 되돌리기를 원하는 시점이 작업 시점과 상당히 떨어져 있는 경우, 그 시점에서 '컨펌'은 진정한 의미가 없으니까, 즉 물어도 소용 없으니까 빼는게 좋겠죠. 예를 들어 '편지 보내기'를 되돌리고 싶은 경우는 두 가지인데, 하나는 '실수'로 보내기 버튼을 누른 경우랑, 다른 하나는 '내용 번복'으로 보낸 편지를 회수 하고 싶은 경우죠. 이 때 전자는 번복 시점이 바로 인접해 있으니까 컨펌 메시지가 의미가 있지만, 후자(내용 번복으로 인한 보내기 취소)는 번복 시점이 대개는 보내기 시점과 떨어져 있으니까 (편지 보내놓고 한참 뒤에 후회하거나, 내용상 실수를 발견하죠) 컨펌 메시지가 아무런 의미가 없죠. 이 때 UI Designer가 고려해야 할 것은 전자/후자의 발생 확률과 그에 따른 치명도인데, 제 생각에 전자의 경우 확률도 낮고, 위험도도 높지 않다고 생각합니다. 저도 제 인생에서 두 세 번 정도 편지를 완성하지 않고 실수로 보내기 버튼을 누른 경험이 있지만, 그게 그렇게 위험했던 적은 없었다고 봅니다. (물론 그런 경험이 있는 사람도 있었겠지만...)

그러나 또한 모든 UI Design 원칙들이 그러하듯이, 이러한 원칙과 복잡한 예외에도 불구하고 규칙만으로 설명할 수 없는 감정적인 부분이 있습니다.

사실 이 글을 쓰게 된 동기도... 최영완씨가 이 부분에 대한 의문을 제기하는 것이 아닐까 하는 생각에서 시작했는데...

흔히 쓰기 쉬운 UI ...에서 많은 사람들이 착각하고 있는 것이... 바보를 위한 UI를 설계하려고 한다는 겁니다. 누구나 쓰기 쉬운 UI를 만든다고 하는 것이 결국 아무 것도 모르는 바보를 위한 UI를 만들어 버리는 거죠. 물론 그 바보가 쉽게 쓸 수 있다면, 다른 사람들도 그것을 쉽게 쓸 수 있겠죠. 그러나 그러면서 사람들은 스스로 자기 자신에 대해 바보로 느껴지는 기분을 피할 수가 없게 되고, 점점 그 소프트웨어가 싫어지게 됩니다. 논리적으로 보면 당연히 그렇게 하지 않을 것 같지만, 많은 초보 UI Designer들이 실제로 이런 실수를 하고, 때로는 Microsoft 같은 큰 회사의 전문가들도 이런 실수를 하게 됩니다. 이전 버전 Office의 Paper Clip처럼 말이죠.

이것은 흔히 HCI의 4대 요소 가운데 하나인 Level of Support를 지칭하는 것은 아닙니다. 또한 최근 다시금 유행하는 다양한 사용자 프로파일링 기법으로 피할 수 있는 문제만도 아닙니다. 사용자의 전문성이나 외부적인 도움과는 어느 정도 별도로 분명히 주의해야 할 문제라고 생각합니다.

좋은 소프트웨어는 자신감이 있어야 하고, 또한 쓰는 사람에게 자신감을 불어 주어야 합니다. UI 는 그렇게 만들어져야 한다고 생각합니다. 쓰는 사람을 바보로 취급하고 바보로 만들어서는 안됩니다.

예를 들어 어떤 사장과 비서와의 대화를 들어 보시죠.

어느날 오전

사장 : 이 편지를 보내 주게.
비서 : 그러니까 이 편지를 보내란 말씀입니까?
사장 : 그래. 보내라니깐. (뭐야... 한국말을 모르나?)

잠시 후

사장 : 이 편지도 보내 주게.
비서 : 그러니까 이 편지를 보내란 말씀이죠?
사장 : 그래. 보내라구. (뭐야... 무슨 불만있나? )

그 날 오후

사장 : 이 편지 좀 보내 주게.
비서 : 그러니까 이 편지를 보내란 말씀인가요?
사장 : 그래. 보내란 말이야. 그리고 앞으로 내가 편지 보내라고 말할 땐, 편지를 보내라는 뜻이야. 그러니까 그냥 보내. 보낼 거냐고 다시 묻지 말고. 알았어?

이와 같은 서비스를 사람인 '비서'가 제공한다면 정말 한심한 노릇이 아닐 수 없습니다. 마찬가지로 편지 보내기 버튼도... 내가 보내라면 그냥 보내야지, 내가 '정말' 보내기 원하는지 물어본다는 것은 어처구니 없는 일인 것 같습니다. 거기서 발생할 수 있는 실수는 다른 방법으로 해결해야지, 한 번 더 물어본다는(Confirm) 방식으로 해결해서는 안된다고 생각합니다. 이것은 소프트웨어 자신을 바보로 만들 뿐만 아니라, 쓰는 사람도 바보로 만들어 버리는 일이기 때문입니다.

그 날 밤...

사장 : (곤란한 표정으로) 어... 아침에 보내라고 했던 편지 말이야... 보냈어?
비서 : 보냈죠. 그래서 제가 꼭 되물었잔아요.
사장 : 허... 그 때야 당연히 보내야 한다고 생각했지. 지금 생각해보면, 그거 보내지 말았어야 하는데...

사람들에게도 이러한 일이 생기는데, 이런 문제가, 비서가 매번 'Confirm'을 받는다고 해결되는 것은 전혀 아닙니다.

물론 소프트웨어가 어떤 작업에 있어서 얼마나 자신감을 가져야 하느냐는 것은, 또한 모든 UI 원칙이 그렇듯이 구체적인 상황에 따라 달라진다고 생각합니다. 따라서, 해당 작업의 구체적 상황에 따라 Confirm 메시지를 보내야 하느냐 말아야 하느냐가 결정되겠죠. 이메일을 보내는 매카니즘과 상황이 일반적인 사용자들에게는 꽤나 안정적이고 일반적인 작업이 되어 가면 갈 수록, 구체적 진행 상황 보고(예를 들면 송신 서버와의 교신 상태 등 - N씨의 UI 원칙에 보면 항상 시스템의 상태를 표시하라는 황당한 규칙이 나오는데 이에 대해서는 다시 이야기할 기회가 있을 겁니다.)과, 각 소 단계에서의 Confirm들은 점점 표시할 필요 없는 일이 될 것입니다. 더욱 더 일반적인 작업이 되면, 이제 최종적으로 보낼 건가, 말건가의 Confirm 조차도 필요없는 일이 되겠죠. 편지 보내기는 이 단계에 와 있다고 생각합니다.

그 작업 자체가 시간이 많이 걸린다든지, 기타 리소스를 많이 먹는 '중대' 사안이어서 소프트웨어가 어느 정도의 자신감을 가지고 스스로 판단해서 결정해야할지 어려울 수도 있는데, 예를 들어 편지를 보내려면 전화 통화중이더라도 그것을 끊고 모뎀 접속을 해야 한다든지, 아니면 현재 컴퓨터가 상당히 느린데 거기다가 편지 보내기 작업까지 하면 중대 작업에 방해가 될 확률이 있다든지 하면 소프트웨어가 스스로 판단하기 어렵겠죠. 그러나 오늘날 편지 보내기 작업은, 특정 작업(서버로의 송신)을 분리시키든, 아니면 최소한 컴퓨터 처리 능력이 다른 거 하면서 편지 보내기 기능은 할 정도가 된다고 판단했든간에 어떤 경우라도 이 정도는 사용자의 Confirm 없이 진행할 수 있는 단계에 와 있는 것 같습니다.

앞의 경우가 소프트웨어와 사용자가 동시에 바보가 되는 경우라면, 소프트웨어 자신은 빛나면서 사용자를 바보로 취급하는 경우도 있습니다.

원치도 않는데 이러쿵 저러쿵 옆에서 잔소리를 하는데, 그 잔소리가 틀린 거 반, 맞는 거 반이라면 정말 짜증나는 일입니다. 제 친구는 오피스 클립에게 이렇게 소리를 지르더군요. "I am a native speaker of English. I know English grammer!" 이렇게 소프트웨어 자신은 자신감에 차서 헛소리를 하더라도, 사용자의 자존심을 긁어서는 안되는 거죠. 설령 그것이 맞는 지적이더라 하더라도 말입니다. 흔히 도움말이 없는 것 보다는 있는 것이 무조건 훨씬 낫다고 생각하는 소위 '전문가N'들도 많은데, 제 생각은 적절하지 않은 도움말은 Screen real estate를 점유하든, user cognitive load를 점유하든, 무언가 차지함으로서 마이너스 요소가 있을 뿐만 아니라, 심리적으로도 사용자를 '바보'로 만들고 자부심과 자신감을 떨어뜨릴 수 있다는 점에서 조심해야 할 요소라고 생각합니다. 이것은 바로 제품에 대한 '충성도' 하락으로 연결되겠죠.

물론 이런 거만한 태도의 소프트웨어 뿐만 아니라 겸손하면서 쉽게 만들어진 소프트웨어도 사용자들에게 상처를 줄 수 있죠. 어떤 직종의 경우는 다른 전문가들 틈에서 작업을 해야 하기 때문에 자신이 작업하는 화면이 상당히 어렵게 보이는 것을 사람들이 은근히 즐기고 있었는데, 어느 사용성 전문가라는 사람이 나타나 그 화면을 쉽게 만들어 버리자, 자기 자신에 대한 self-esteem도 낮아져 버리고, 주위 사람들의 시선 또한 곱지 않을 것을 예상했는지, 거부해 버리는 경우가 생긴 사례를 본 적이 있는데, 이 경우 소프트웨어를 너무 쉽게 만들어 버림으로서 문제가 된 상황일 수 있습니다. 이 경우는 S/W UI 뿐만 아니라, 작업 관행에 대한 개선까지 동시에 이루어져, 이 직군의 사람들에게 좀 더 고급의 임무를 부과하는 정치적 고려가 필요하겠죠.

이제 이 글의 결론을 내야 할 것 같습니다. 처음 시작할 때, 제가 이렇게 썼는데...

"일단 제 간단한 생각은... 물어볼 필요가 없기 때문이라는 것이 제 생각입니다. 흠... 다시 질문을 바꾸어 보면... 왜 물어봐야 하죠?"

다른 모든 것을 고려할 때, 이 문제는... 상식적으로 없는게 좋을 것 같습니다.

이상이 제 생각입니다...

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

HCI 게시판에 글을 처음 올리다 보니... 좀 떨리는군요... 다들 아시는 내용으로 중언부언한 건 아닌지... 엉뚱한 방향으로 아는체 한 건 아닌지 걱정이 됩니다. 혹시 제 글에 다른 생각을 가지고 계신 분이 있다면... 언제라도 답글 달아 주세요... 고맙습니다.

이 재 용

(주)피엑스디 대표