Joel on Software

Joel on Software 조엘 온 소프트웨어

 

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

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

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

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

 

프로그래머를 위한 사용자 인터페이스 설계론
제9부: 제품 제작 절차


글 : Joel Spolsky
번역 : AhnLab
2000년 5월 9일 화요일

지금까지 좋은 설계의 원칙에 대해 이야기하였다. 그러나 이것은 모두 기존 설계를 평가하고 향상시키기 위한 방법을 제시해 주는 것들이다. 그렇다면 도대체 처음에는 어떻게 설계를 해야 하는가? 대부분의 사람들은 생각할 있는 모든 기능 특성에 대한 그림을 그리는 것이 우선이라고 한다. 그리고 나서 각각 세부적인 것을 설계하고 메뉴 아이템(또는 페이지)에서 제거하는 하는 단계를 거친다. 작업이 완성되면 프로그램 (또는 사이트) 원하는 모든 기능을 갖게 된다. 그러나 이는 옳은 절차가 아니다. 사용자들은 그러한 프로그램이 무엇을 하는지, 어떠한 방법으로 자신이 원하는 것을 성취할 있도록 하는지 알지 못한다.


마이크로소프트는 활동 기반의 기획 (Activity Based Planning)이라는 해결책을 소개하였다 (내가 아는 , 개념은 엑셀 팀의 Mike Conte 고안해 내었다. 자신의 직업에 싫증을 느낀 그는 지금은 2 직업인 카레이서로서 활동하고 있다). 중요한 것은 사용자의 활동 이해하고 이러한 활동을 쉽게 달성할 있도록 하는 초점을 맞추는 것이다. 이는 다음에서 자세하게 설명되고 있다.


각종 카드를 만들 있는 사이트를 제작하기로 했다고 가정하다. 일종의 순진한 접근 방법을 사용해 다음과 같은 특성 목록을 만들 있었다.

  

1. 텍스트를 카드에 첨가
2.
그림을 카드에 참가

3. 자료실에 미리 디자인된 카드를 사용
4.
카드 보내기:
      a.
이메일로 보내기
      b.
출력하기



문제를 생각할 있는 좋은 방법이 없는 관계로 일반적인 매킨토시 사용자 인터페이스인 circa-1984 기본으로 하기로 했다. 프로그램은 카드를 보여주고, 메뉴에서 텍스트 삽입, 그림 삽입, 자료실 카드 받기, 카드 보내기 등을 선택할 있다. 사용자가 해야 하는 일은 컴퓨터 앞에 앉아 메뉴를 오고 가며 사용되는 모든 명령어를 이해하고, 어떻게 하면 이런 개별 명령어를 사용하여 카드를 만들 있는지를 알아내는 것이다.

활동에 기반을 기획에서 디자이너는 사용자가 취할 있는 일련의 행위를 생각해 필요가 있다. 가상의 사용자를 고려해 , 가장 중요한 “3가지 떠올릴 있다.

  1. 생일 카드
  2. 초대 카드
  3. 기념일 축하 카드

프로그래머의 입장에서 자신의 프로그램을 보는 것이 아니라 (카드를 만들기 위해 어떤 기능들이 필요한가를 생각하는데 있어서), 사용자가 어떠한 행위를 취할 것인가를 사용자의 입장에서 생각해 보라.

  1. 생일 카드 발송
  2. 파티 계획 손님 초대
  3. 기념일 축하 카드 발송

갑자기 온갖종류의 생각이 물밀듯이 떠오를 것이다. 아무 것도 없는 백지 카드로 시작하는 것이 아니라 다음과 같은 메뉴로 시작할 수도 있을 것이다.


무엇을 하고 싶으세요?

  • 생일카드 발송
  • 기념일 카드 발송
  • 파티 초대 카드 발송
  • 스스로 꾸미기

메뉴를 뒤질 필요가 없기 때문에 갑자기 사용자는 프로그램을 사용하는 것이 훨씬 쉽게 느껴질 것이다. 프로그램이 사용자를 여러 단계를 거치도록 유도함으로써 행위를 완성시킬 있다 (사용자의 행위를 제대로 선정하지 못한 경우, 오히려 프로그램을 사용할 있는 사용자들을 혼란 시킬 있다. 예를 들어 하누카 (유대인 명절) 카드를 보내려고 하나 선택사항에 없을 있다. 따라서 목표하고자 하는 시장의 대부분을 커버할 있는 활동을 선택하는 주의를 기울여야 한다).


3가지 행위의 리스트에서는 프로그래머가 추가를 원할 있는 좋은 기능들이 있다. 예를 들어, 만약 생일 카드나 기념일 축하 카드를 보낼 경우 내년에도 동일한 사람에게 카드를 보낼 있도록 상기시켜 주는 기능을 갖고 싶을 있다. 따라서 내년에 알림 기능 체크 박스에 추가할 있다. 파티 초대 카드는 RSVP (참석 여부를 알려주세요) 추가할 필요가 있다. 따라서 사람들로부터 RSVP 전자 메일로 수집할 있는 기능을 추가할 있다. 이러한 기능에 대한 아이디어는 애플리케이션이 지원하는 기능이 아니라 사용자가 수행하는 행동을 관찰한 결과 도출된 것이다.


이것은 사소한 예시에 불과하다. 그러나 매우 중요한 애플리케이션의 경우 행동 기반의 프로그램 기획이 가져다 주는 열매는 훨씬 값지다. 프로그램을 아무것도 없는 처음부터 설계할 , 프로그래머는 사용자가 취할 있는 행위에 대한 비전을 이미 가지고 있어야 한다. 이러한 비전을 갖는 것은 그렇게 어려운 것은 아니다. 동료들과의 브레인스토밍, 소비자 활동 목록의 작성 그리고 초점을 맞춰야 활동 선정 등의 방법을 통해 별다른 노력 없이도 비전을 가질 있다.  그러나 이러한 행위에 대해 생각하고 이를 차근차근 종이에 적어 나간다면 전체적인 프로그램 설계에 도움을 것이다.


행위 기반의 기획은 이미 사용되고 있는 제품의 2번째 버전을 만들 더욱 중요하다. 현재 사용되고 있는 프로그램의 사용용도를 살펴보기 위해 사용자 샘플을 관찰할 있겠다.


엑셀 1.0에서 엑셀 4.0 나올 때까지, 마이크로소프트의 직원 대부분은 사람들이 엑셀을 재정상태에 대한 가상 시나리오 (what-if) 만들기 위해 사용한다고 생각했다. 예를 들어, 인플레이션 율을 변경하고 이것이 이윤에 어떠한 영향을 미칠 것인지 알아보기 위해 사용한다고 생각했다.


활동 기반의 기획을 사용해 만든 최초의 공식 버전인 엑셀 5.0 다자인 , 엑셀 사용자를 관찰하는 과장을 추가했다. 5번째 사용자를 관찰할 때부터 대부분의 엑셀 사용자들이 제품을 리스트 작성에 사용한다는 것을 알게 되었다. 공식을 입력한다던가 계산을 위해서는 전혀 하지 않았던 것이다. 그때까지 이에 대해 전해 알지 못했다. 결국 리스트를 만드는 기능이 엑셀의 다른 기능보다 훨씬 널리 사용되고 있다는 것이 밝혀지면서, 이를 바탕으로 우리는 리스트 관리를 보다 쉽게 있는 많은 기능들을 추가하였다. 쉬운 분류, 자동 데이터 입력, 리스트의 일부를 있도록 하는 AutoFilter 기능, 엑셀이 자동적으로 모든 것을 조정하고 있는 동안 동일 리스트를 동시에 여러 사람이 작업할 있도록 하는 멀티 유저 기능 등이 포함되었다.


엑셀 5.0 설계 하는 동안 Lotus Improv라로 하는 새로운 패러다임 채용한 스프레드시트를 출시했다. 언론 발표에 따르면 Improv 스프레드시트의 신세대로 기존에 사용되던 모든 스프레드시트를 대체할 정도로 강력하다는 것이었다. 여러 가지 이상한 이유로 인해 Improv 처음에는 NeXT 실려 판매되었고, 판매 실적은 별로 좋지 못했다. 그러나 사람들은 VisiCalc 애플 II 탑재되면서 애플 컴퓨터의 매출을 높였던 처람 Improv NeXT 판매에 공헌을 것으로 믿었다. 프로그램은 그야말로 대박 프로그램이어서 (killer app) 이를 사용하기 위해 사람들이 기꺼이 새로운 하드웨어를 구입할 것이라 생각했다.


Improv 지금 역사의 사건쯤으로 기억되고 있다. 인터넷에서 Improv 찾아보면 검색 결과라고는 팔리지 않는 재고 물건을 파는 웹사이트를 운영하는 거대한 창고 운영자의 웹사이트 링크가 전부이다.


그럴까?  Improv 리스트를 만드는 기능이 없었다. Improv 디자이너들은 소비자들이 복잡한 다차원 재무 모델을 작성하는데 스프레드시트를 사용하고 있다고 생각했던 것이다. 만약 이들이 소비자들에게 직접 물어 봤다면 리스트 작성 기능이 다차원 재무 모델을 만드는 것보다 널리 사용되는 기능이었다는 것을 알았을 것이다. Improv에서는 리스트를 만드는 것이 완전 불가능하지 않았을지라도 만드는 자체가 매우 힘들었다.


따라서 활동 기반의 기획 방법은 애플리케이션을 처음 기획하는 단계에서 매우 유용하다. 이를 통해 사용자들이 무엇을 원하는지 추측할 있기 때문이다. 업그레이드 버전을 만들 방법은 더더욱 도움이 된다. 기존의 프로그램을 가지고 고객이 무슨 목적으로 사용하는지를 있기 때문이다.


다른 예로 deja.com 진화를 있다. deja.com Usenet으로 불리는 dejanews 거대한 서치 인덱스로 개발되었다. 초기 화면에 있고 거기에는 이러저러한 것을 찾으려면 Usenet 검색하세요 (search Usenet for blah)라고 쓰여 있었고, 사실 사이트는 잡다한 지식을 찾는 것이 목적이었다. 1999 활동 기반의 기획이 일부 진행되었고 결과 발견된 하나의 공통된 사용자 행위는 어떤 차를 사야 할까?” 같은 제품 서비스에 대한 조사였다. Deja 이러한 서비스 제공자로 확실히 각인되었고, 현재 제품 견해 조사 서비스를 제공하고 있다. Usenet 서치 기능에 대해서는 알려진 바가 전혀 없다. 이는 Usenet 사용해 자신의 Matrox 비디오 카드가 Redhat Linux 5.1 호환이 되는지 알고 싶어 검색을 원하는 일부 사용자들은 이에 대해 불평을 하였다. 그러나 단지 가장 좋은 디지털 카메라를 사고 싶어하는 대다수의 사용자들에게는 만족스러운 서비스였다.


활동 기반의 기획 방법이 뛰어난 면은 또한 추가되지 말아야 기능이 무엇인지 있도록 한다는 것이다. 종류에관계없이 소프트웨어를 프로그램할 , 시간에 비례해 3배나 많은 기능을 생각해 내는 것이 상례이다. 어떤 기능을 추가하고, 어떤 기능을 배제해야 하는지 결정하는 가장 좋은 방법은 어떤기능이가장중요한사용자활동을지원하는가를평가하는것이다.


가상의사용자


업계 최고의 UI 디자이너들은 모두 하나같이 말하기를 UI 디자인을 하기 전에 제품을 사용할 잠재적 고객을 상상해 내고, 이들의 특성을 기술할 있어야 한다고 말한다. 책의 서문에서 소개했던 가상의 사용자 피트를 기억할지 모르겠다.

피트는 기술관련 출판사의 회계사로 지난 6 동안 사무실과 집에서 윈도우 프로그램을 사용했다. 그는 능력도 있고 기술에 밝은 사람으로, 소프트웨어를 스스로 설치할 있고, PC 잡지를 구독하며, 심지어는 간단한 워드 매크로를 프로그램하여 사무실의 비서가 송장을 발송하는 것을 돕기도 했다. 집에 케이블 모뎀이 있고, 전에 매킨토시를 이용한 적이 전혀 없다. "매킨토시는 너무 비싸요,"라는 것이 그의 의견이다. "700 Mhz PC with 128 Meg RAM 내장된 700 Mhz PC 가격은요…" 피트, 고만해요. 충분히 알겠습니다.


위의 글을 읽으면서 사용자를 상상해 있을 것이다. 이와는 상당히 다른 종류의 사용자도 생각해 있겠다.

패트리샤는 영문학 교수로 평이 좋은 시집 권을 저술하였다. 그녀는 1980년부터 워드 프로그램을 위해 컴퓨터를 사용해 왔지만 지금까지 Nota Bene (학술분야에서 사용된 옛날 워드 프로세서) 마이크로소프트의 워드 2개의 프로그램만을 사용해 보았다. 그녀는 컴퓨터의 작동원리를 배우기 위해 시간을 소비하기를 원치 않으며, 자신의 파일을 되는 대로 여기 저기 디렉토리에 관계없이 저장한다.


피트를 겨냥한 소프트웨어를 설계하는 것은 패트리샤를 위한 소프트웨어를 설계 하는 것과 상당히 다르다. 또한 집에서 리눅스를 사용하고 IRC 대해 관심이 많으며 “Micro$oft” 소프트웨어를 거의 사용하지 않는 16세의 소년 마이크를 위한 소프트웨어를 설계하는 역시 무척 다를 것이다.


이런 각양 각색의 사용자를 염두에 두고 있다면 자신이 만드는 프로그램이 적합한지 아닌지 쉽게 있다. 많은 수의 프로그래머들은 일반 사용자의 능력을 훨씬 과대평가한다. 사용하기 힘든 명령어 라인 인터페이스를 만들 마다, 이메일을 받곤 한다. 명령어 라인 인터페이스를 사용하면 'gunzip foo.tar.gz | tar xvf -' 같은 것도 있기 때문에 것이 훨씬 강력하다는 것이다. 그러나 패트리샤가 복잡한 라인을 입력하고 있는 모습을 상상해 보면 이런 종류의 인터페이스가 그녀의 요구를 전혀 충족시켜주고 있지 못한다는 것은 자명해 진다. 제품을 사용할 진짜 사용자를 생각함으로써 프로그래머는 사람들의 요구를 충족시켜 기능을 창조하는 있어 감정을 공유할 있다 (물론, 고급 시스템 관리자들을 위한 리눅스 백업 소프트웨어를 만들고 있다면 프랭크 같은 인물을 생각하면 것이다. 프랭크는 윈도우를 만지기조차 싫어하며, 자신이 개조한 tcsh 버전을 사용하고 있고, 하루 종일 4개의 연결된 (tiled) xterms 사용해 X11 운영한다).


정리하자면, 좋은 소프트웨어를 설계하기 위해서는 6개의 단계를 거쳐야 한다.

  1. 가상 사용자를 창조한다.
  2. 중요한 활동을 이해한다.
  3. 사용자모델 구상한다. – 이러한 활동을 달성하기 위해 사용자는 어떻게 해야 하는가?
  4. 설계 초안을 만든다.
  5. 설계 작업을 여러 반복하여 가상 사용자들의 능력으로도 쉽게 취급될 있을 정도로 쉽게 만든다.
  6. 개발된 소프트웨어를 사용하는 실제 사용자를 관찰한다. 사용자들이 어려워하는 부분이 어디인지 확인한다. 그러면 프로그램 모델이 사용자 모델과 일치하지 않는 부분을 발견할 있게 것이다.

UI 훌륭하면 소프트웨어가 팔릴 아니라 사용자들에게 기쁨을선사할있다. 왜냐하면 사람들은 자신이 이루고자 하는 것을 달성했을 행복감을 느끼기 때문이다. 이것이 바로 UI 디자인이 보람이 있는 업무 영역인 이유이다. UI 디자인 이외의 어느 분야에서 수백만 명의 사림들을 조금이나마 행복하게 있는 기회를 발견할 있을 것인가 





이 기사는 영어로 User Interface Design for Programmers Chapter 9: The Process of Designing a Product 라는 이름의 기사가 원본입니다. 

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