퍼소나로 완성하는 인터랙션 디자인 About Face 3

조화로운 인터랙션 디자인 (10장. 디자인 오케스트라) 

1. 사용자의 멘탈 모델을 따른다.
2. 적을수록 많은 것이다.
   • 제품의 기능은 그대로 살리면서 인터페이스상의 시각적 요소를 줄이는 일
3. 단순하게 조작할 수 있어야 한다. 사용자가 많은 생각을 하지 않게 하라.
   • 가장 이상적인 인터랙션은 대화상자 없이 간단한 툴과 도구로 조정하는 것이다.
   • 잔소리하는 기계를 만들지 말라.
4. 가까운 곳에 필요한 도구를 배치한다
   • 초보자나 중급자에게는 팔레트, 툴바에서 원하는 도구를 선택한다. 전문가에게는 키보드 단축키로 접근할 수 있게 만들자. 이런 방식으로 모든 사용자가 쉽게 단일 클릭이나 키보드 조작으로 도구를 선택할 수 있다.
   • 만약 사용자가 어떤 도구를 찾으려고 프로그램에서 헤매야 한다면 작업의 전체적인 집중도를 크게 떨어뜨릴 것이다.
5. 모드형 대화상자는 피한다.
6. 사용자의 입장에서 중요한 디자인에 초점을 맞춘다. 극도로 예외적인 경우에도 대처한다.
   • 대부분의 경우 일어날 만한 상황과 어쩌다 일어날 수도 있는 예외의 경우를 확실히 분리해야 한다.
   • 문서에서 작업한 내용을 일부러 취소하려고 하는 경우가 얼마나 될까? → 자동 임시저장하는 것과 저장 프로세스를 임시보관으로 처리하는 것의 차이. 왜 저장에서
7. 문맥적 정보를 제공한다.
8. 직접적 조작법과 시각적 입력법을 가능하게 한다.
9. 애플리케이션의 상태를 알려준다.
10. 불필요한 보고는 생략한다.
    • 사용자는 컴퓨터 내부의 구체적인 정보까지 일일이 알 필요가 없다.
    • 이유없이 대화상자를 열어가며 정보를 전달하는 건, 특별한 이득 없이 사용자의 흐름만 방해할 뿐이다.
11. 백지장 상태는 피한다.
    • 사용자가 아무 생각도 없을거라 쉽게 가정하지 말자. 사용자가 모든 일을 다 알고 있다고 가정하지도 말자. 원하는 게 뭔지 알아내려고 이것저것 물어보는 일도 자제하자.
    • 능숙한 파워 유저가 아닌 이상, 일반 사용자가 원하는 바를 하나하나 일일이 설명해내는 일은 쉽지 않다.
    • 오히려 소프트웨어가 생각하는 것이 맞다고 믿으면서 프로그램이 제시하는 대로 그대로 따라가는 걸 당연하게 생각한다.
12. 허가가 아닌 이해를 구한다.
    • 통계적으로 가장 가능성이 있는 경우의 수를 제시함으로써, 사용자가 완전히 처음부터 시작하지 않도록, 최소한 어디에서부터 시작을 해야할지 알맞은 기반을 잡도록 도움을 준다.
    • 어떤 행동을 해야할지 '허가'를 구하기보다, 일어난 사실에 대해 '이해'를 구하는 편이 더 현명하다.
    • 아무 정보도 없이 완전 처음부터 시작하는 것은 어렵다. 당연히 누가 만들어놓은 기본 세팅위에서 시작하는 편이 훨씬 쉽다.
    • 덜 위험하고 쉬운 방법으로 프로그램이 제공하는 기본값을 사용자가 원하는대로 미세하게 조정할 수도 있다.
13. 명령과 설정은 명확히 구분한다.
14. 묻지마라. 선택하게 하라.
    • 질문을 하는 것과 선택의 기회를 제공하는 것은 엄연히 다르다.
    • 확인용 대화상자의 태도는 사용자에게 결정을 하라고 종용한다. 반면, 도구상자는 사용자의 결정을 도와주도록 가능한 옵션을 알려준다.
15. 비상탈출 손잡이를 조심스럽게 배치한다.
16. 빠른 응답을 위해 최적화하고, 늦어질 경우에는 적절히 조절한다.
    • 지금 사용중인 프로그램이 시간을 많이 요구하는 작업을 자주 해야할 수도 있다.
    • 너무 오래 기다리지 않으면서 사용자가 적절한 인터랙션을 경험할 수 있는 실현 가능한 실행 방법을 해결책으로 제시해야 한다. 지체를 유발하는 요소를 취소할 수 있는 방법을 준비해두자.

---

버전 생성과 회귀

• 점진적 되살리기는 꼭 필요하다. 다만 목록이 필요 이상 길어지는 것을 경계할 뿐이다. 버전을 생성한다는 것은 전체 문서의 복사본을 남기는 일이다. 시간 단위로 사진을 찍어 일상의 기록을 남기는 행위에 비유할 수 있다. 버전을 생성할 때는 문서를 통째로 저장하기 때문에 파일 시스템과도 관련이 있다. 버전 생성은 사용자의 자발적 요청에 의해 만들어진다는 점에서 그 밖의 되살리기 시스템과 차별화된다. 사용자 스스로 문서의 복사본을 저장한다. 복사본을 생성한 뒤에는 안심하고 원본을 편집할 수 있다. 나중에 편집한 내용이 마음에 들지 않으면 이전에 저장해놓은 복사본을 열면 된다.
• 개발자는 중요한 소스 코드를 저장하기 위한 방편으로 흔히 버전을 생성한다. 한편 코드 외의 영역에서 버전 개념은 아직까지 생소하다. 효과적인 버전 생성을 위해서는 회귀revert 명령어를 어떻게 디자인할 것인지가 가장 중요하다. 우선 저장된 버전의 전체 목록을 사용자에게 제공한다. 이때 각 버전에 대한 부연설명이 필요하다. 생성 날짜와 시간, 만든 사람, 문서 크기, 그 밖에 사용자가 추가로 메모한 내용이 있으면 표시한다. 각 버전의 차이점을 이해하고 회귀할 버전을 고른다. 사용자가 선택한 버전으로 회귀하면 여태껏 작업하던 문서는 새로운 버전으로 저장된다.

저장 인터랙션의 재발견

• 데이터 저장에 관한 내부적 매커니즘을 사용자가 맞닥뜨려야 할 이유가 전혀 없다. 그럼에도 불구하고 강제로 들이민다. 당황스러운 것은 당신과 어머니 뿐만이 아니다. 컴퓨터를 제법 능숙하게 다루는 사용자라 할지라도 곧잘 헷갈리거나 실수할 수 있다. 사용자는 하드웨어와 소프트웨어를 구입하는 데 수백만원을 처들였다. "하루 종일 뼈 빠지게 작업한 문서를 과연 저장해야 할까요?"라는 멍청한 질문이나 듣자고 그 돈을 들인 게 아니라는 소리다. 복사본을 만들려면 '다른 이름으로 저장하기' 명령어를 눌러야 한다는 것 쯤은 기본 상식이라는 태도도 어이없다.
• 지켜본 바에 의하면 파일 시스템, 즉 애플리케이션과 데이터 파일을 저장하는 디스크 장치의 개념을 잘 이해하는 사용자는 많지 않다. 이것은 컴퓨터의 가장 핵심적인 요소다. 오류가 발생할 경우 치명적인 결과를 초래할 수 있다. 사람들은 주기억장치와 디스크 저장장치를 명확히 구별하지 못한다. 하지만 소프트웨어 디자인을 보면 마치 모든 사용자가 둘의 차이점을 당연히 알고 있다는 식이다.
• 최근에 웹 애플리케이션과 그 밖의 데이터베이스 지향 소프트웨어가 성행하기 시작했다. 파일 시스템에 대한 기존의 구현 모델적인 접근 방식을 벗어던질 절호의 기회였다. 그러나 안타깝게도 비슷한 문제가 반복됐다. 문서와 설정을 변경할 때마다 사용자는 매번 '적용하기' 혹은 '변경사항 저장하기' 버튼을 눌러야 한다. 사용자에게 시스템적인 사고방식을 강요하는 것이다. 주기억장치와 디스크 저장장치가 클라이언트/서버 구조로 대체됐을 뿐이다.
• 파일 관리와 저장하기에 관한 여러 가지 인터랙션 방법을 살펴보자. 사용자의 멘탈 모델에 가장 근접한 방식은 무엇인지 생각해보자.

변경한 문서 저장 : 대체 뭐가 문제죠?

• 실행 중인 애플리케이션은 두 개의 위치에 공존한다. 열린 파일은 모두 마찬가지다. 메모리와 디스크에 동시에 존재한다. 기술적으로는 이것이 최선이다. 즉시 반응할 수 있는 데이터(메모리)와 미래에 대비해 저장해놓은 데이터(디스크)의 메커니즘이 상이하기 때문이다. 하지만 상식에는 어긋난다. 사용자(물론 개발자는 예외다)의 멘털 모델에 존재하는 문서는 단 하나뿐이다. 우리가 만들고 변형할 수 있는 한 개의 문서만이 존재한다.
• [변경사항 저장하기] 대화상자에는 명백한 오류가 있다. 저장하기와 저장하지 않기는 동등한 확률의 행동이 아니다. 하지만 대화상자는 이 둘을 아주 공평하게 취급한다. 실제로 사용자가 '아니오'를 선택할 확률은 예를 선택할 확률에 비해 현저히 낮다. 열심히 작업한 문서를 누가 저장하지 않고 싶어하겠는가.
• 이왕 물을 거라면 어째서 문서에 변화가 생겼을 때 즉시 묻지 않는 걸까? 왜 꼭 닫을 때까지 기다렸다 물을까? 문서를 닫는 것과 저장하는 것은 전혀 별개의 행동이다. 본질적으로 아무런 관련도 없다. 사람들이 대화상자를 받아들이는 이유는 그 흐름이 자연스러워가 아니다. 단지 컴퓨터의 방식에 익숙해졌을 뿐이다.
• 닫기 혹은 종료 버튼을 눌렀을 때 [변경사항 저장하기] 대화상자를 발행하는 이유가 있다. 컴퓨터가 메모리에 있는 문서와 디스크에 있는 복사본의 차이를 조정해야 하는 시점이기 때문이다. 기술적 측면에서 접근하면 닫기 혹은 종료하기와 저장하기를 연결하는 것이 자연스럽다. 하지만 인간적인 입장에서 보면 연결고리가 없다. 방을 나설 때 우리는 방이 그 상태 그대로 머물기를 기대한다. 읽던 책을 덮을 때마다 매번 적어놓은 메모를 전부 지우는 사람은 아무도 없다.

---

통합 파일 모델 디자인

• 잘 디자인한 소프트웨어라면 문서를 단일한 것으로 취급해야 한다. 디스크의 복사본과 메모리의 복사본으로 분리해서 취급하면 절대 안 된다. 통합 파일 모델unified file model에서 사용자는 굳이 컴퓨터의 내부적 메커니즘을 상대할 필요가 없다. 파일 시스템이 알아서 디스크와 메모리 사이의 데이터를 관리한다.
• 대부분 애플리케이션의 표준 파일 운영체제는 '열기', '저장하기', '닫기'를 기본으로 구성된다. 여기에 '다른 이름으로 저장하기', '변경사항 저장하기', '열기' 대화상자가 추가되는 형태가 일반적이다. 이들 대화상자는 곧잘 사용자를 헷갈리게 만든다. 심지어 주어진 태스크를 전혀 수행하지 못하는 경우도 허다하다. 사용자의 멘탈 모델을 좀 더 훌륭히 뒷받침할 수 있는 문서 운영 방법.
• 우선 문서를 단일 개체로 취급하는 것이 가장 중요하다.
  • 자동으로 저장하기
  • 복사본 만들기
  • 버전 생성하기
  • 파일명 지정하고 바꾸기
  • 파일 위치 지정하고 바꾸기
  • 문서 포맷 지정하기 
  • 변경사항 복구하기
  • 이전 버전으로 복구하기

자동으로 저장하기

• 애플리케이션은 문서를 자동으로 저장해야 한다. 사용자가 작업을 끝마치고 닫기 기능을 소환하면 애플리케이션은 주저하지 말고 변경사항을 디스크의 복사본에 적용한다. 쓸데없이 [다른 이름으로 저장하기] 대화상자를 불러내서 작업 흐름을 가로막지 않도록 주의한다.
• 이상적인 상태라면 이것으로 끝내도 충분하다. 하지만 컴퓨터와 소프트웨어는 언제 고장 날지 모른다. 애써 작업한 내용을 언제 잃어버릴지 알 수 없다. 사용자가 미처 저장하기도 전에 전원이 꺼져버리면 메모리가 손상되고 변경사항이 삭제된다. 물론 디스크의 복사본은 안전하다. 하지만 마지막 저장 이후로 여러 시간 동안 작업한 내용이 모조리 날아가 버렸다. 이런 사태를 방지하려면 애플리케이션이 일정한 시간 간격으로 문서를 자동 저장해야 한다.
• 사용자가 원할 때 수동적으로 저장할 수 있는 기능이 반드시 필요하다. 하지만 사용자가 의무적으로 저장하기를 실행해야 하게끔 디자인해서는 안된다.

복사본 만들기

• 복사본이란 원본과 내용이 일치하되 물리적으로는 전혀 상관없는 별개의 파일을 뜻한다. 원본에 아무리 수정을 가해도 복사본에는 아무런 영향도 끼치지 않는다. 예를 들어 '알파'라는 이름의 파일이 있으면 '알파 복사본'이라는 파일명의 복사본을 자동으로 생성해야 한다. 이미 그 파일명을 가진 문서가 있으면 '알파 복사본 #2'라는 파일명으로 복사본을 만든다. 복사본은 원본과 동일한 디렉토리에 저장한다.
• 복사본 만들기를 대화상자에 담고 싶은 유혹에 빠지기 쉽다. 하지만 절대로 흔들리면 안 된다. 애플리케이션은 이 기능을 조용하고 효과적으로 센스 있게 처리해야 한다.

위치 지정하고 바꾸기

• 문서를 완전히 새로 작성하기보다는 이미 존재하는 문서를 편집해야 하는 경우가 더 많다. 백지 상태로 작업을 시작하는 경우는 흔치 않다. 기존의 문서를 열어서 작업하는 경우가 일반적이다. 파일 시스템의 어딘가에 이미 위치를 확보하고 있는 셈이다. 처음 문서를 생성할 때 혹은 처음 저장할 때 위치를 지정하게 하는 건 고정관념에 불과하다. 새 파일은 사용자가 쉽게 찾을 수 있는 곳에 저장해야 한다.
• 파일을 저장하기에 가장 적합한 장소는 사용자와 제품의 성격에 따라 달라진다. 매일 사용하는 복잡한 애플리케이션은 전용 문서 디렉토리를 따로 지정해주는 것이 좋다.
• 애플리케이션은 기본적으로 모든 파일의 위치를 자동으로 지정해야 한다. 굳이 다른 곳으로 옮겨야 할 경우에만 대화상자를 부른다.

변경사항 복구하기

• 사용자가 의도치 않게 명령을 실행한 경우에 이를 되돌릴 수 있는 방법이 필요하다. 이러한 경우를 대비해 우리가 잘 아는 도구가 있다. 바로 되살리기다. 파일 시스템은 되살리기의 대용품이 아니다. 되살리기 기능을 뒷받침할 수 있는 매커니즘인 것은 사실이다. 하지만 사용자가 이것을 파일 시스템의 주된 용도로 인식하게 해서는 안된다. 파일 시스템에 들어가 직접 변경사항을 취소하게끔 하는 건 되살리기 기능을 죽이는 일이다.

변경사항 모두 버리기

• 때로는 변경사항을 모두 취소하고 싶을 때가 있다. 문서를 연 이후로 발생한 모든 변경사항을 한꺼번에 취소하고 되살릴 수 있는 기능이 필요하다. 파일 시스템을 이해하지 않고도 사용자가 목적을 달성할 수 있어야 한다. '변경사항 모두 버리기 기능'을 메뉴에 추가하면 간단히 해결된다. 이전 버전을 복구하는 것도 좋은 방법이다.
• 버전 체계에 대해서는 잠시 후에 설명하겠다. 모두 버리기 기능은 심각한 데이터 손실을 초래할 수 있으므로 눈에 잘 띄는 경고성 문구를 반드시 삽입한다. 모두 버리기 기능을 되살릴 수 있는 방법도 물론 마련해야 한다.

버전 생성하기

• 버전을 생성하는 것은 복사본을 만드는 일과 유사하다. 차이점이 있다면 버전은 애플리케이션이 직접 관리한다는 점이다. 사용자는 각 버전을 통틀어서 하나의 문서로 인식한다. 사용자는 버전이 생성된 각 순간으로 언제든지 되돌아갈 수 있다. 애플리케이션은 사용자에게 버전 목록을 제공한다. 목록에는 생성 시 해당 버전의 문서로 작업 중인 파일이 교체된다. 동시에 작업 중이던 문서는 새로운 버전으로서 저장된다.