디자인과 인간 심리 - 도널드 노먼 책 리뷰

학지사, 도널드 노먼 저자, 박창호 역

 

가방에 넣어두면 엄청 오래읽은 것 처럼 책이 고대의 것이 된다.

도입

 

처음 이 책을 구입한 이유는 내가 "나만의 것을 만들어 내는 것”에 관심이 많기 때문이다. 

 

이미 개발을 통해서 만들어 내고 있잖아? 라고 생각할 수 도 있고 실제로 그렇기도 하지만, 지금 실무에서 느끼는 감정으로, 그리고 내가 혼자서 사이드 프로젝트를 하는 감정으로는 개발은 "만들어 내는 것”에 해당하는 것 같다. 여기에는 “나만의 것을”이 결여되어 있는데, 이를 채워줄 무언가가 필요했다.

 

왜 개발은 “나만의 것”이 결여 되었다고 생각을 했는가? 이유는 개발을 진행함에 있어서 정해진 정답 비슷한 것이 존재하고, 내가 아닌 다른 사람이 같은 작업을 한다 하더라도, 같은 결과를 뽑아낼 수 있어보였다. 심지어 실력적으로 확실히 나보다 뛰어난 개발자는 나의 시행착오 코드가 무가치하게 만들 만큼 완벽한 상위 호환의 것을 만들어 내는 분야라고 생각되었다. (비관적으로 말하는 것 같지만, 나는 여전히 개발을 사랑한다. 그리고 나만의 것을 “만들어 내는 힘”은 정말로 중요하다.)

 

그래서 나는 정말 “나만이 할 수 있는, 세상에 하나 뿐인”것을 원했고, 이는 자연스레 내가 평상시에 로망으로 생각하던 글쓰기, 그림 그리기, 작곡하기와 같은 분야에 관심으로 이어졌다.

이와 함께 개발과 병합해서 이미 가진 나의 능력을 사용할 수 있는 것은 무엇일까? 바로 디자인 이라는 생각을 하였다. 디자인과 개발 능력을 합쳐서 온전히 나만의 아이디어, 나만의 물건을 만들어 내는 것이 가능할 것이라고 생각한 것이다.

 

그래서 어떻게 디자이너가 되는가를 리서치하고 찾은 책이 바로 도널드 노먼의 <디자인과 인간 심리(The Design of Everyday Things)>이다. 

 

첫 인상

 

나는 책을 볼 때 저자 소개를 꼼꼼히 확인한다. 내가 생각하기에 책이 읽을 가치가 있는지 알려주는 가장 중요한 지표는 그 작가의 커리어와 내 관심사가 일치 하는가 여부인대, 그 이유는 내 관심사에 대해서 깊은 이야기를 해줄 수 있는 사람인지가 중요하기 때문이다.

노먼의 커리어는 내가 지금 고민하고 있던 부분(인간 심리, 디자인, 실용성)을 정확히 커버하는 사람이었다.

 

그리고 오래된 책은 언제나 읽을 가치가 있다고 생각하는데, 이 책은 무려 25년간 무수히 많은 디자이너들에게, 그리고 디자인에 관심있는 일반 독자들에게 읽혔다. 그렇다고 너무 오래된 예시를 사용해서 사람들이 공감을 못하는게 아니고 최근 개정을 통해 최신 예제로 업데이트 하였고 이미 해결된 문제에 대해서는 제거하거나 새로 발생한 문제에 대해서 추가하는 작업을 하였다고 한다. 

말 그대로 많은 사람들이 오랜 기간 찾을 만큼 고전인데 그 내용을 갱신해서 트랜드에 뒤쳐지지 않는 책인 것이다. (적어도 첫 인상은 그랬다.)

 

디자인에 일자무식인 나도 접근하기 쉬운 예시들을 다룬다는 점에서 마음 편안하게 하고 읽기 시작한 것 같다.

 

1장 생활용품의 정신병리학

 

사용성 좋은 제품은 무엇일까? 무엇이 먼저 떠오르는가? 나는 UX와 관련된 책이라고 하면 복잡한 얘기가 먼저 나올 줄 알았다. 그런데 1장 생활용품의 정신병리학 에서는 완전히 내 생각을 깨버렸다.

 

왜 출입문이나 스위치, 수도꼭지 또는 레인지 같은 것에 곤란을 겪어야 하는가? (p.21)

이 문은 아니고, 이런 문이였다.

나도 어렸을 때 당기는 문을 미는 문으로 착각하고 돌진해서 다친 경험이 떠올랐다. 단순히 부끄러운 경험이지만, “난 왜 당기는 문을 미는 문으로 생각했지?”에 대한 생각은 해본 적이 없다. 그건 단순한 내 실수라고 생각했기 때문이다.

하지만 노먼은 여기에 대해서 단호히 디자인의 잘못이라고 말한다. 

 

내가 본 문은 미는 쪽과 당기는 쪽의 디자인이 완벽히 동일 했는데, 투명한 유리창에 문을 조작하기 위한 손잡이가 달려있는 형태다. 그렇다 문이 스스로 밀어서 열어야 하는지 당겨서 열어야 하는지에 대한 아무런 정보를 제공하지 않는 것이다. 내가 돌진해서 다친 이후에는 항상 주의해서 밀고 당기기를 선택했지만 처음부터 더 나은 디자인은 없었을까?

 

나는 뭘 보고 물건의 사용법을 판단할까? 이에 노먼은 인간 심리 관점에서 이를 설명했다.

 

행위 지원성 : 물건의 속성과 행위자의 능력의 상관 관계다. (내가 지금  타이핑 하는 키보드의 키 버튼은 내가 “누르는 행위”를 지원한다. 또한 책상은 이러한 키보드를 “받치는 행위”를 지원한다.)

 

기표 : 행동이 어디에서 일어나야 하는지 암시하고 전달한다. (행위 지원성은 단순히 동작이 가능하다는 것이다. 가령 모바일 앱을 사용하는 입장에서 우리는 “터치하는 행위” 지원성을 가지고 있지만, 전화를 걸기 위해서 우리는 "전화기 모양의 아이콘”을 누른다. 아이콘이 하나의 기표이다.)

 

제약 : (3-4장 내용에서 자세하게 리뷰 하겠다)

 

대응 : 두 집합의 요소 간의 관계성을 의미한다. (우리 집에 스위치만 보더라도 두개의 스위치가 달려있고 각 스위치를 누르는 행위는 각 조명의 on/off에 대응된다.)

 

피드백 : 사용자의 행위에 대해서 시스템에서 정보를 알려 준다. (모바일 앱에서 버튼을 눌렀을 때, 버튼이 똑딱 거리는 그래픽이 그것의 예이고, 당신이 아이디를 입력하지 않고 로그인 버튼을 눌렀을 때 아이디를 입력해 달라는 응답을 제공하는 것이다.)

 

개념 모형 : 물건이 어떻게 작동하는가?에 대한 하나의 단순화된 설명, 장치 그 자체를 통해 추론되거나 설명서를 통해서 추론 될 수 있다.(설명서는 매우 복잡하므로 사람들은 본인의 필요나 이해에 의해 자체적인 단순한 “심적 모형”을 만들어 낸다.)

 

그리고 좋은 디자인이라는 것은 이러한 판단을 사용자들이 물 흐르듯 자연스럽게 할 수 있도록 하는 것이다.

 

이러한 개념들이 어느정도 공감되나? 필자는 실제 모바일 앱 프로덕트를 생산하며 고민한 부분과 상당 부분 일맥상통 한다는 생각에 신나서 읽었다.

(그리고 이 책은 나머지 장에서 각 지표에 대해 자세하고 재밌는 예시를 들어서 설명한다. 여기까지 흥미가 생긴다면 꼭 일독을 권한다.)

 

3장 머릿속의 지식과 세상 속의 지식

 

이 장의 내용이 내가 이 책에서 가장 충격적인 내용인대, 쓴다는 것과 다른 사람의 지식을 사용하는 것, 그리고 책을 읽는 것에 대한 내 전반적인 마인드를 뒤집어 버렸기 때문이다. 

 

이 책의 주장에서 지식은 크게 두가지로 나뉘는데 하나는 머리속의 지식과 세상 속의 지식이다.

 

머리속의 지식은 말 그대로, 사용자의 단기 기억과 뇌의 어딘가에 저장되는 장기 기억을 포괄하는 지식이다. (암산을 할 때 중간 값들은 단기 기억에 저장을 하고, 3번 째 전 집의 문잡이가 왼쪽에 있는지 오른쪽에 있는지 기억하는 것은 장기 기억이다)

 

세상 속의 지식은 책과 같은 글이나 안내 음성 메시지 처럼 내가 굳이 기억하지 않아도, 언제든지 꺼내 볼 수 있는 지식이다.(물론 나는 이런 안내를 보기 위해 세상 속 지식이 여기에 있다는 머리속 지식을 사용해야 할 지도 모른다)

 

매우 간단한 예로, 내가 컨퍼런스나 새로운 사람을 만나는 자리를 가는 경우가 떠오르는데, 이 때 처음 보는 사람의 이름을 듣고 한참 얘기를 하다보면(그 사람의 이름이 머리속 지식형태로 나에게 남아있다) 어느순간 그 사람의 이름을 잊게 되는 경험을 한 적이 있다. 하지만 어떤 자리에서는 명찰이 준비되어 있고 간단한 자기 소개 이후에는 명찰에 적힌 이름(그 사람의 이름은 명찰 형태로 세상 속 지식이 되었다)을 보고 그 사람의 이름을 불러야 할 때 명찰을 보고 부르면 되었다.

 

나는 단기 기억력이 나쁜 편인 것 같은데, 그 이유는 새로 만나는 사람들의 이름을 그 순간 외우는 것이 매우 어렵고, 비단 이름 뿐만 아니라 어려운 수학 문제를 풀거나 프로그래밍 문제를 풀 때면 나는 종이와 팬(머리속 지식을 세상속 지식으로 편입시킨다)이 없으면 풀어나갈 수 없었기 때문이다.

 

그래서 요즘 같이 디지털이 잘 발달한 시대에서 캘린더와 메모, 리마인더, 알람은 내가 해당 사건에 대해서 기억할 필요성을 없앴고, 그로인해 나는 내 머리가 나빠졌다고 느끼기 일쑤였다.

그래서  의도적으로 그런 기억 보조 장치들의 사용을 줄이려고 하였다.

 

그러나 3장을 읽고 이러한 기술의 발달을 통해 물건이 잘하는 정밀한 기억은 물건에게 책임을 넘기고, 사람은 사람이 좀더 잘하는 그 행위가 필요한 이유와 같은 상위 수준에 이슈의 초점을 맞춰야 한다는 것을 깨달았다. 내 내면의 스트레스를 줄이고 좀더 건설적인 방향으로 생각을 바꾸게 되었다. (기술의 발달을 적극 활용하기로 하였다)

 

그리고 서비스 제작 관점에서도 중요한 내용인데 사용자의 머릿속 지식에 과도하게 의도하는 서비스는 사용하기 어려울 수 있다는 생각을 하게 되었다는 것이다. 그래서 우리가 서비스를 제작할 때, 사용자가 세상 속의 지식(우리가 서비스에서 기표를 통해 자연스럽게 드러나거나, 자연스러운 대응을 통해 부가 설명 하지 않더라도 사용성이 좋은)을 사용할 수 있게 조직화 해야 한다는 생각이 들었다.

 

4장 할 일 알기: 제약, 발견 가능성 및 피드백

 

사용자가 우리의 시스템을 파악하는 데 중요한 요소로 세상 속의 지식을 활용 할 수 있다고 했다. 그렇다면 어떻게 사용할 것인가?가 이번 4장의 주요 논제이다.(나는 실제로 서비스를 만들어야 하니 집중해서 읽었다)

 

글로 써놓은 것은 세상 속의 지식이다. 사용자는 아무것도 모르는 상태에서 그 글을 읽고 시스템에 대한 이해를 할 수 있을 것이다. 하지만 글의 의도 전달이 잘못되는 경우를 우리는 많이 봤다. 그리고 글 이외에도 다양하게 세상 속에 시스템에 대한 가이드를 두는 것이 가능한데, 4장에서 주요하게 다루는 것은 제약, 발견 가능성 그리고 피드백이다. 

 

제약은 4가지로 분류하여 소개하는데

물리적 제약 : 가능한 조작을 제한하는 것이다, 사용자에게 해당 행위는 불가능 하다는 것을 즉각적이고 명확한 피드백을 주는 샘이다. (모바일 앱에서 사용자가 서버로 부터 데이터를 받아오는 버튼을 눌렀을 때, 데이터가 다 그려지기 전에 다시 버튼을 누르는 것을 막기 위해 로딩창을 띄워준다.)

 

문화적 제약 : 사회적 상황에 따라 일단 허용 가능한 행위가 있기에, 그에 행위에 제약을 받는다. (한국을 대상으로 제공되는 서비스는 텍스트를 왼쪽부터 오른쪽으로 읽는 순서로 제공하고, 카드 뉴스의 흐름 또한 왼쪽에서 오른쪽으로 제공한다. 이는 한국에서 글을 읽는 문화와 관련이 있다.)

 

의미적 제약 : 주어진 상황의 의미에 따라서 가능한 행위의 집합을 제어하는 것이다. (회원 가입 화면을 보면, 모든 입력 필드는 위에서 아래로 쓰이게 된다. 사용자는 이러한 모든 입력 필드의 맨 아래에 제출 버튼이 존재할 것이라는 사실을 의미적으로 유추할 수 있다.)

 

논리적 제약 : (-내가 정확히 이해하지 못함-)

 

제약에 대한 이 의견은 서비스 개발과 팀 문화 구축에 관심있는 요즘 내게 매우 와닿는 부분 이였다. 

 

프로그래머가 서비스를 개발할 때 자유로운 언어 (포인터를 이용해 하드웨어를 직접적으로 다루는 C 같은 언어)보다 제약을 걸어서 포인터의 사용을 막은 언어를 더 선호하는 것 처럼, 빠른 적응과 작업을 하기 위해서는 행위자에게 가능한 케이스에 최대의 자유를 주는 것이 아니라 의미있는 것들에 한한 제약을 거는 것이 좋다고 생각을 했었기 때문이다.

 

또한 팀 문화 구축도 마찬가지로 각 반복 주기마다 팀원과 일을 하며 서로 안 맞았던 부분에 제약을 걸며 발전시킨다. 그렇게 팀에서 허용되는 행위와 그렇지 않은 행위들이 모여서 문화를 만들어 가지 않는가

 

제약이라는 어감이 주는 부정적인 의미보다 더 긍정적인 의미 그리고 더 실용적으로 활용할 수 있다고 생각이 들었다. (그러면서 제약 광신도가 되었다)

 

내가 생각할 때 가장 직관적인 제약은 물리적 제약인데, 이것은 사용자로 부터 부적절한 행위를 원천적으로 차단 시켜버린다. 문화적 의미적 제약은 각 팀의 문화, 각 나라의 문화, 각 직업의 문화에 따라서 의도한 대로 제약일 수 도 있고 아닐 수도 있다. 의미적 제약도 마찬가지다. 

그리고 이러한 물리적 제약은 행위 지원성 자체를 제거하는 것으로 달성 할 수 있다. 문의 예시에서 손잡이를 달고있는 미는 문은, 손잡이가 함축하는 당기기 행위 지원성 때문에, 행위자는 별다른 제약 없이 당기는 행위를 시도할 수 있고, 이는 오작동(문이 안열림)을 의미한다. 반면에 미는 문에 단순히 판만 덧대어 두면 판은 당기기 행위 지원성 자체가 없기 때문에 사용자는 미는 동작으로 강제될 것이다.

 

앱 서비스 관점에서 이런 물리적 제약은 버튼이 여러번 클릭 되어 다중 작업 지시하는 것을 방지하기 위해 연기되는 버튼 클릭을 제작 하거나, 로딩바를 추가해 추가적인 사용자 액션이 아예 불가능 하게 만들어 버릴 수 있다. 또 라디오 버튼의 경우 단 하나만 선택될 수 있게 다른 라디오 버튼을 클릭하면 같은 그룹의 체크되어 있던 라디오 버튼을 자동으로 꺼줄 수 도 있다.

 

5장 인간 오류? 아니, 나쁜 디자인

 

“아 그렇게 사용하면 안돼요.”

 

내가 앱 개발을 처음 할 때, 많이 했던 생각이다. 왜 앱을 그렇게 쓰지? 일부러 앱을 죽이려는 건가? 뭐지? 이런 생각을 많이 했고, 그게 내 잘못이 아니라 그런 독특한 사용자 탓을 했었다.

그리고 5장은 이런 생각이 얼마나 철없는 생각인지 철저하게 보여주는 책이다. 그리고 생각보다, 위와 같은 생각을 하는 사람이 많다는 것, 그리고 그런 사람들의 결정이 얼마나 잘못된 일인지를 예시를 들어가며 설명하는 장이다.

 

책은 인간 오류라는 말이 얼마나 의미없는 말인지를 설명하기 위해서 오류가 무엇인지, 어떻게 생기는지, 보고가 얼마나 중요하고 오류를 보고하는 문화를 만들기 위해서 어떻게 해야하는지를 설명한다.

 

오류가 무엇인지 2가지로 나누어 설명하는데

실수 : 목표는 맞는데, 행위가 제대로 되지 않은 경우 (퇴근을 하려고 나왔는데 퇴근 태그를 안찍고 자동 문 여는 버튼을 누르고 가는 경우, 외출을 했는데 버스 카드를 챙기지 않아서 버스를 못타고 집으로 돌아오는 경우, 맥 컴퓨터를 사용하다가 윈도우 컴퓨터를 가끔 사용하면 한영 대신 CapsLock 키를 누르는 경우)

 

착오 : 목적이나 평가 자체가 제대로 되지 않은 경우 (상대방의 이야기를 듣고 그와 관련된 대답을 하려다가 이야기가 다른 길로 새는 경우, 약속 장소로 이동하는 중에 주변이 매우 안 익숙하다고 생각했는데 그러려니 하며 잘못된 길로 걸어간 경우)

 

이러한 오류의 원인은 무엇일까? 그것은 주로 방해 때문 이라고한다. 

우리는 오류에 대해 특정 사람에게 그 책임을 무는 경향이 있다. 가령 의사의 의료 과실은 막중한 업무 강도로 인해 수면이 부족한 의사의 오류일 것이다. 여기서 의사에게 책임을 무는 것이 나은가 아니면 수면 부족을 유발한 시스템 디자인을 변경하는 것이 옳을까?

 

또 마찬가지로 나는 오류의 원인이 나라고 생각하는 경향이 있다. 내가 집중을 재대로 하지 못하는 상황이 오면(그런 경우는 카페에서, 직장에서, 술자리에서 무궁무진하게 일어난다), 나를 탓한다. 내가 좀더 잘하면 되지 않았을까?

 

하지만 노먼은 그렇게 단순하게 생각할 문제가 아니라고 지적한다. 오류의 원인을 사람으로 돌리는 것은, 시스템 디자인의 발전 측면에서 굉장히 좋지 않은데, 이는 결과적으로 오류 가능성을 내포한 시스템의 개선을 하기 어려운 상황으로 변질된다는 것이다. 사람만 체벌하고 왜 그 사람이 그 오류를 범할 수 밖에 없었는가 에 대한 고민이 없다면 그런 오류를 범하는 사람은 꾸준히 생성될 것이다.

 

빠르게 실패하고 빠르게 피드백 받자

 

오류는 보고되어야 한다. 하지만 나의 경우만 봐도 오류를 나의 실수로 치환한다. 가령 얘를 들어보자. 내가 맥과 윈도우를 번갈아 가면서 작업을 하는데, 윈도우에서 내가 사용하던 맥 단축키가 동작하지 않는 경우, 나는 나의 숙련도를 탓하게 될 것이다. 절대로 시스템의 문제라고 보지 않겠지만, 사실 맥과 윈도우에서 동일한 단축키를 지정할 수 있지 않을까? 유사한 단축키를 지정할 수 있지 않을까? 비슷한 단축키를 지정한다면 맥을 사용하던 윈도우를 사용하던 해당 서비스를 이용하는 사람은 덜 혼란할 것이다. 그리고 이는 오류 보고 없이는 발견하기 어렵다.

 

나만 보지말고, 내가 지금 만드는 제품의 사용자 관점으로 가보자. 사용자들은 우리의 제품만 사용하는 것이 아니다. 사용자는 현실 세계로 부터 방해를 받는다. 우리가 생각하는 흐름대로 서비스를 이용하지 못하는 고객은 차고 넘칠 것이다. 서비스를 이용하다가 중간에 상사가 불러서 휴대폰을 끄고 가는 경우, 서비스를 이용하다가 중간에 네트워크가 불안정한 터널로 들어간 경우, 서비스를 이용하다가 중간에 전화를 받는 경우 등 사용자는 언제든지 흐름을 방해받을 수 있다. 그리고 방해 이후에 우리 서비스로 돌아오면 오류를 발생 시킬 수 있다. 흐름상 누르지 않을 거라고 생각한 버튼을 누를 수도, 본인이 열심히 작업한 내용을 전부 강제 삭제할 수 도 있는 것이다. 

이는 오류다. 하지만 언제든 발생 가능한 오류이고 사람의 행위가 잘못된 것은 아니다. 

 

행위를 오류로 취급하지 마라. (p.245)

 

행위를 오류로 취급하지 말고, 모든 가능한 케이스를 분석하자. 사용자가 버튼을 눌렀을 때, 발생할 수 있는 모든 케이스에 피드백을 주는 시스템을 디자인 할 수 있을 것이다.

사용자가 로드 버튼을 눌렀는데 네트워크 통신이 끊어져 있나? 최근 기록의 아이템을 보여줄 수 있으면 보여주자. 혹은 네트워크가 끊겼다고 시스템 팝업을 띄워주자.

사용자가 작업을 하다가 뒤로가기 버튼을 눌렀을 때, 해당 작업물이 뒤로 가면 유지 되지 않고 사라질 거라는 경고를 보여주고, 의식적으로 작업을 저장하게 도와주자.

사용자의 휴대폰 정책 문제로 화면이 파괴 되었다가 다시 그려진다면? 우리는 화면의 데이터들을 유지시키고 사용자는 자신의 작업이 유지 될 수 있게끔 하자.

 

절대로 행위에 문제를 삼지 말자.

 

6장 디자인 생각하기

 

이 장은 에자일 방법론이 떠오르는 장이다. 반복을 통한 점진적인 개선, 빠르게 실패하며 사용성 좋은 서비스 디자인 하기가 그것이다.

그리고 새로 배운 것은, 해결책을 찾기 위해서 처음에 재기된 표면적 문제가 아닌 실재 해결책을 찾기위해 이러한 반복작업이 돌아야 한다는 것이다. 그를 위한 방법론으로 이중 다이아몬드 발산-수렴 디자인 모델이 있다. (이와 관련된 글들은 많으니 관심있으면 찾아보시길…)

 

위의 방법론들 보다 나에게 더욱 와 닿은 부분은 “방금 내가 말한 것? 실제로 그런 식으로 작동하지 않아 (288.p)”다. 정말 정곡을 찌르는 부분인데, 에자일 방법론 공부도, 그 어떤 소프트웨어 개발 방법론 공부도 실제에서는 현실적인 벽에 막히는 부분들이 존재하기 마련이기에 유사하게 느껴졌다.

그 이유는 각 부서와 협업하는 디자이너의 특성상 다른 부서의 요구사항 때문에 방해받는다.(판매 부서는 빠른 시간에 적절한 제품이 나오길 원한다. 그리고 개발자 입장으로 안드로이드의 특수성을 고려한 디자인, 혹은 이미 작업된 레거시 서비스 구조에 추가하기 힘든 디자인 요소를 마주할 때, 반대 의견을 내고, 내 생각대로 변경 됐으면 좋겠다고 생각한다.)

 

그래서 이에 대한 노먼의 유쾌한 법칙을 작성했는데

 

어떤 제품 개발 과정이 시작하는 날, 그것은 이미 일정에 뒤처졌으며 예산을 초과한다. (p.289)

 

그러니 디자인은 도전적인 분야다. 사용성 좋은 제품을 만들기 위해 디자인을 하면서도 외부와(심지어 같은 팀과) 의견을 조율하며 이상과 현실의 줄타기를 해야한다.

 

전체 느낀바

 

이 책은 사람이 쓰는 무언가를 만드는 누구나 읽어 보는게 좋다. 

 

디자인이 무엇일까. 마냥 멀게만 느껴졌던 분야인데 이 책을 읽으니 바로 옆자리에 있던 친구같은 느낌으로 변했다. 

 

이 책이 소개하는 디자인은 내가 앱을 개발하며 한 고민들, 읽었던 책들, 소프트웨어 개발 방법론과 유사하다. 심지어 서로 보완하여 시너지가 난다.

 

앱 개발을 하는 친구들은 이 책을 꼭 읽으면 좋을 것 같다. 인간 오류(라고 생각되는 것)은 디자이너가 커버할 수 있다. 하지만 OS의 오류, 프로그램의 오류는 프로그래머가 커버할 수 있는 영역이다. 이런 오류도 마찬가지로(물론 짜증은 나지만) 시스템에 영향을 주어선 안된다. 에러 처리에 대한 기본적인 개념이 증강되었다.

 

또한 사용자의 피드백 관점에서 기본 철학을 탑재하게 되었다. 사용자가 앱에서 어떤 동작을 하는 경우, 사용자의 의도가 들어간 행위에 대해서는 모종의 피드백을 주어야한다. 그것이 심지어 오류여도 마찬가지다. 왜 오류인지, 언제 시도하면 좋은지 피드백을 주어야한다. 그래야 사용자는 피드백을 통해 서비스에 대해 학습하고 스스로의 개념 모형을 구축할 수 있다.

 

결국 실용적인 디자인 기술에 대해 다루는 책은 아니다. 하지만 디자이너라면 가져야 하는 디자인 철학에 대해서 다루는 책이다. 철학을 다루는 책이지만, 전혀 지루하지 않다. 오히려 풍부한 예제와 경험에서 묻어나는 노먼만의 언변이 이 책을 굉장히 재밌게 읽히게 만들어준다.

 

그리고 도널드 노먼의 팬이 되었다. 단지 책 하나를 읽었을 뿐이지만, 이 사람이 가진 자신의 분야에 대한 애착이 느껴진다. 흔히 말하는 괴짜같다. 나는 괴짜를 좋아한다. 그리고 괴짜는 말에서, 글에서 그런게 묻어나는 것 같다. 그래서 다음 읽을 책도 도널드 노먼의 책으로 결정했다. <도널드 노먼의 디자인 심리학>이 그것이고, 이 글을 적고 있을 때 이미 내 옆 서재에 가지런히 꽂혀있다.

영롱한 초록색이 인상적이다.