Joel on Software

Joel on Software 조엘 온 소프트웨어

 

프로그래머를 위한 사용자 인터페이스 설계론
제1부
제2부
제3부
제4부
제5부
제6부
제7부
제8부
제9부

한글로된 다른 "Joel on Software" 글들

영어로된 다른 "Joel on Software" 글들

필자 메일주소(영어만 사용)

 

프로그래머를 위한 사용자 인터페이스 설계론
제6부: 바쁜 사용자들에게 어필하는 설계


글 : Joel Spolsky
번역 : AhnLab
2000년 4월 26일 수요일

사용자 인터페이스 설계시, 다음과 같은 원칙을 명심하는 것이 좋다.

  1. 사용자는 사용설명서가 없으며, 있더라도 읽지 않는다.
  2. 사실 사용자는 아무 것도 읽을 없으며, 읽을 있더라도 읽지 않을 것이다.

엄격하게 말하자면 이것들은 사실이 아니지만 이것들이 사실인 것처럼 행동해야 한다. 왜냐하면 그렇게 하면 프로그램 사용시 용이하면 친근한 느낌을 주게 되기 때문이다. 이러한 생각을 염두에 두고 설계를 하는 경우 사용자존중이라는 말을 쓰는데 말은 사용자에 대해 그다지 존중하지 않는다는 것을 의미한다. 혼동된다면 지금부터 설명하겠다.

 

사용을 용이하게하다라는 말의 뜻은 무엇인가? 용이성을 측정할 있는 한가지 방법으로서 실제 세상 사용자의 퍼센트가 주어진 시간 내에 작업을 완료할 있느냐를 알아보는 것이다. 예를 들어, 프로그램의 목적이 사용자로 하여금 디지털 카메라 사진을 사진앨범으로 전환할 있도록 하는 것이라고 가정해 보자. 일반 사용자와 함께 같이 앉아서 프로그램을 사용해서 주어진 작업을 한다면, 프로그램의 유용성이 높을수록, 사진앨범을 성공적으로 제작하는 사용자 퍼센티지가 높을 것이다. 과학적으로 얘기하자면, 100명의 사용자가 있다고 가정해 보자. 사용자들이 컴퓨터에 대해 알고 있을 필요는 없다. 사용자들은 서로 상이한 재능이 있고 일부는 눈에 정도로 컴퓨터에 대한 재능이 없다. 일부는 주어진 프로그램을 사용하려 혼란스러움을 느꼈다. 전화벨이 울리고. 뭐라고? 애가 울고 있고. 뭐라고? 그리고 고양이가 책상으로 뛰어 올라가 쥐를 쫓고 있고. 들려!

 

이러한 실험을 하지 않고도, 일부 사용자는 작업을 완료하지 못하거나 완료하더라도 엄청난 시간이 걸릴 것이라는 것을 어느 정도의 확신을 가지고 말할 있다. 이런 사용자들이 바보 같다는 말이 아니다. 오히려, 사용자들이 머리가 좋을 수도 있고 아니면 성공한 운동선수일 수도 있다. 하지만 주어진 프로그램에 관한 , 자신들의 운동기술 뇌세포를 프로그램을 사용하는데 쓰지 않는 것뿐이다. 사용자들의 관심의 대략 30% 받고 있는 셈이다. 컴퓨터에 대해 알지 못하는 것처럼 보이는 사용자들이 익숙하게 사용할 있도록 만들어주어야 하는 것이다.

 

사용자들은사용설명서를읽지않는다.

무엇보다도, 사용자들에게 사용설명서가 없다. 사용설명서가 없을 수도 있다. 있더라도 다양한 논리적 이유로 인해 사용자가 가지고 있지 않을 수도 있다. 사용자가 비행기를 타고 있는 경우, 웹사이트에서 다운로드 받은 데모 버전을 사용하는 경우, 집에 왔는데 사용설명서가 직장에 있는 경우, IS 부서에서 사용설명서를 적이 없는 경우 . 사용설명서가 있는 경우라도, 차선책이 전혀 없는 경우를 제외하곤 사용자들은 사용설명서를 읽지 않는다. 아주 드문 예외를 제외하곤, 소프트웨어를 사용하기 전에는 사용설명서를 읽지 않을 것이다. 일반적으로 사용자들은 뭔가를 이루려고 하는데 사용설명서를 읽는다는 자체를 시간 낭비라고 생각하거나 적어도 현재 하고 있는 작업에 대한 집중에 방해가 된다고 생각한다.

책을 읽고 있다는 사실만으로 매우 박식한 엘리트 그룹에 속하게 된다. 물론 컴퓨터를 사용하는 사람이라면 글을 읽을 안다는 것은 알고 있다. 장담하는데 상당 퍼센티지가 읽는다는 자체를 허드렛일이라고 생각할 것이다. 사용설명서의 언어가 모국어가 아닐 수도 있는데 외국어 능력이 충분치 않을 수가 있다. 사용자가 아이들일 수도 있다. 반드시 필요한 경우라면 사용설명서를 해독 있겠지만 그럴 필요가 없으면 물론 읽지 않을 것이다사용자는 엄격하게 필요한 경우에만 배운다라는 기본 전제 아래 사용설명서를 읽는다.

 

모든 것의 최종 결과는 소프트웨어를 설계할 밖에 없는 상황이기에 처음에는 사용설명서가 필요치 않다. 내가 생각할 있는 유일한 예외는 사용자에게 해당 분야의 지식이 없는 경우일 것이다 프로그램의 목적이 무엇인지 모르지만 일단 배우는 데에는 일가견이 있는 경우일 것이다. 이런 경우의 알맞은 일례가 Intuit 매우 인기 있는 소규모 자영업 회계 프로그램 QuickBooks이다. 프로그램 사용자의 다수가 회계에 대해 전혀 모르는 소규모 자영업자이다. QuickBooks 사용설명서는 이러한 점과 사용자에게 기본적인 회계 원리를 가르쳐야 한다는 가정을 한다. 밖의 다른 방법은 없다. 하지면 회계에 대해 알고 있는 경우, 사용설명서 없이도 손쉽게 QuickBooks 사용할 있다.

 

사실, 사용자들은아무것도읽지않는다

 

말은 가혹하게 들릴 수도 있지만 사용성 시험을 하게 되면 화면 상의 단어를 그냥 읽지 않는 사람들이 있다는 것을 알게 것이다. 어떤 종류든지 오류 상자를 팝업시키면, 메시지를 읽지 않을 것이다. 팝업 메시지는 프로그래머에게 혼란을 가져다 있는데, 이유는 프로그래머가 자신들이 사용자와 대화를 하고 있다고 상상하게 되기 때문이다. 헤이, 사용자분! 여러분은 파일을 없습니다. 파일 포맷을 지원하지 않습니다! 어쨌든, 경험 , 대화상자의 메시지가 길수록 메시지를 읽는 사용자의 수가 줄어든다는 사실.

 

사용자들이 사용설명서를 읽지 않는다는 사실로 인해, 많은 소프트웨어 설계자들은 사용자들이 작업하면서 여러 가지 사항들에 대해 설명함으로써 사용자를 학습시켜야 한다는 가정을 하게 됐다. 이런 설명은 프로그램의 모든 장소에 나와 있다. 원칙적으로, 이것도 괜찮다. 하지만, 실제적으로 사람들이 읽기를 싫어한다는 사실로 인해 거의 항상 문제가 발생할 것임을 의미한다. 경험 있는 UI 디자이너는 그대로 대화상자의 단어 수를 최소화 해서 사용자가 읽는 확률을 높이려고 한다. Juno에서 일했을 , UI 관계자는 원칙을 이해했기에 짧고, 명료하며, 간단한 문장을 쓰려고 노력했다. 슬프게도, 회사 CEO Ivy League 대학 영문과 출신으로 UI 디자인이나 소프트웨어 엔지니어링에 대한 교육을 받은 적이 없지만 자신을 실력 있는 작문 편집자라는 확신이 있었다. 그래서 그는 전문 UI 디자이너가 작성한 문장을 반대했고 자신의 말을 첨부했다. Juno 일반적인 대화상자는 아래 그림과 같다.

 

 

대화상자와 이에 상응하는 윈도우 대화상자를 비교해 보자.

 

 

본능적으로, 80 개의 단어로 지시사항이 담긴 Juno 대화상자가 5 개의 단어로 지시사항이 담긴 윈도우 대화상자 보다 " 우수하다고" (, 사용이 용이하다)라고 생각할지 모른다. 실제로, 이런 종류의 것들에 대해 사용성 시험을 실행하면 아래와 같은 사실을 발견하게 된다.

  • 숙달된 사용자는 지시사항을 건너뛴다. 사용법은 알고 복잡한 지시사항을 읽을 시간이 없다고 생각한다.
  • 대부분의 초보자는 지시사항을 건너뛴다. 많이 읽는 것을 좋아하지 않으며 디폴트도 괜찮기를 바란다.
  • 진심으로 지시사항을 읽으려고 시도하는(일부는 사용성 시험이고 그러기에 읽어야 한다는 의무감에서 읽음) 나머지 초보자들은 종종 엄청난 글자수와 개념으로 인해 혼동하게 된다. 따라서, 처음으로 대화상자를 접했을 경우 대화상자를 사용할 있을 것이라 확신하는데, 지시사항들은 실제로 초보자들에게 많은 혼동을 준다.

Juno 분명 불필요할 정도로 복잡하고 자세히 설계되어 있었다. 지적하자면, 콜롬비아 대학 영문과 출신인 경우, 언어능력에 있어 평범한 사람들과는 완전히 다른 부류에 속할 것이고 자신에게 도움이 되는 대화 언어선택에 신중을 기해야 한다. 대화를 단축시키고, 한대 뭉뚱그리고, 간단하게 하며, 괄호 중간의 복잡한 구를 삭제하고 유용성 시험을 한다. 하지만, 아이비 리그 교수 메모처럼 보이는 글은 작성하지 않는다. 대화 상자에서 도움이 있고 공손함을 나타내는 "please" 첨부하는 것조차 사람들의 작업을 느리게 것이다.

증가된 단어 묶음으로 인해, 텍스트를 읽는 사용자 수가 측정 가능한 퍼센티지만큼 감소할 것이고.

 

다른 중요한 사항은 많은사람들이컴퓨터를두려워한다는점이다. 점에 대해서는 아마 알고 있을 것이다. 맞지? 하지만 이것이 의미하는 바를 깨닫지 못했을 수도 있다. Juno에서 종료하려는 친구의 시간을 재고 있었다. 이유가 뭔지는 모르겠지만, 종료 상에 문제가 있었다. Juno 종료하려 다음과 같은 대화상자가 팝업된다는 것을 목격했다.

 

 

친구는 No 누른 후에도 Juno 종료되지 않자 놀라고 있었던 것이다. Juno에서 친구가 선택에 대해 질문을 했다는 자체가 그녀로 하여금 뭔가를 잘못했다는 생각이 들도록 한다. 일반적으로, 프로그램에서 명령 확인을 부탁하는 경우, 이유는 나중에 후회할 수도 있는 작업을 지금 하려고 하기 때문이다. 컴퓨터에서 그녀의 판단에 대해 질문 했는데, 결국 컴퓨터는 컴퓨터이고 자신은 단지 인간이기에, 컴퓨터가 틀릴 리가 없다는 가정을 했다. 그래서 "No." 선택했다.

 

11 단어를 읽도록 부탁하면 너무 많은 부탁일까? 글쎄 겉으로 보기엔 그런 같은데 무엇보다도, Juno 종료가 미치는 악영향은 없으니, Juno 현존하는 다른 모든 GUI 프로그램처럼 확인을 묻는 메시지 없이 종료했어야만 했다. 하지만, 종료하기 확인이 매우 중요하다고 확신하는 경우에도, 11 단어 대신 2 단어로 확인이 가능하다.

 

 

전혀 필요치 않은 ”thank you" 후회의 감정을 자아내는 "are you sure?" 포함되어 있지 않은 대화상자로 인해 문제가 발생할 소지가 적다. 사용자는 틀림없이 2 단어는 읽을 것이다. 예를 들어 ", ?" 그런 , Yes 키를 누를 것이다.

 

Juno 종료 확인 대화상자로 인해 몇몇 사람들이 실수함은 확실하다. 이렇게 질문할 수도 있다. 그게 그렇게 커다란 일이야? 누구든지 결국에는 프로그램에서 빠져나올 있을 것이다. 하지만, 사용할 있는 프로그램과 사용이 용이한 프로그램 간의 차이점이 바로 여기에 있다. 혼동하고, 경험이 없는 초보자의 작업이 용이하도록 하는 것이라면, 심지어 총명하고, 경험이 많고 숙달된 사용자라도 기꺼이 그것들을 반길 것이다. 호텔 욕조에는 커다란 손잡이 막대가 있다. 막대는 장애자를 돕기 위해 있다. 하지만, 욕조에서 나올 누구든지 막대를 사용할 있다. 막대로 인해 몸에 이상이 없는 손님들의 삶도 편안하게 된다.

 

다음 장에서는, 마우스에 대해 설명할 것이다. 읽지 않거나, 읽으려 하지 않거나, 읽을 없는 사용자들처럼, 일부 사용자들은 마우스 다루는데 형편없다. 그렇기에 그러한 사용자를 도와야 한다.



> 제7부

이 기사는 영어로 User Interface Design for Programmers Chapter 6: Designing for People Who Have Better Things To Do With Their Lives 라는 이름의 기사가 원본입니다. 

Joel Spolsky는 뉴욕에 위치한 작은 소프트웨어 회사인 Fog Creek Software의 창업자입니다. 예일 대학교를 졸업하고 Microsoft, Viacom, Juno등에서 프로그래머와 매니저로 일했습니다.


이 페이지의 내용은 한사람의 의견을 대변합니다.
All contents Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky