얼마전 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 게시판에 글을 처음 올리다 보니... 좀 떨리는군요... 다들 아시는 내용으로 중언부언한 건 아닌지... 엉뚱한 방향으로 아는체 한 건 아닌지 걱정이 됩니다. 혹시 제 글에 다른 생각을 가지고 계신 분이 있다면... 언제라도 답글 달아 주세요... 고맙습니다.
이 재 용
(주)피엑스디 대표
