♨ mONSTER dESIGN bLOG - 몬스터디자인 블로그

2) 한글판 제목이 상당히 쌩뚱맞다. 차라리 “The inmates are running the asylum”을 그대로 직역하여 “정신병자가 운영하는 정신병원” 비슷하게 했어야 제목과 이 책의 주제를 쉽게 연계시킬 수 있었을 것이다. 

3) 벌써 10년도 넘은 책이라 그런지 사실 큰 감흥은 없다. 게다가 번역도 구글번역기(?) 스타일이라 부드럽게 읽히지도 않고 단어선택에도 문제가 많다. 다만, SW디자인에 있어 Personas 방법론을 최초로 제시한 앨런쿠퍼의 책이라는 데 큰 의미가 있겠다. 

4) 간단 요약 : 정신병자들이 정신병원을 운영하게 되면, 그들은 자신들을 괴롭히는 문제의 본질을 명확하게 보지 못한다. 소프트웨어 기반 제품의 개발자들이 자기 손으로 만든 제품을 검토할 때는 그 제품이 얼마나 나쁜지 잘 발견하지 못한다. 그 제품이 얼마나 끔찍하게 사용하기 어렵고 그것을 익히기 위해 얼마나 많은 시간을 허비해야 하는지, 또 그 제품이 매일 그것을 사용해야 하는 사람들을 얼마나 초라하게 만들고 품위를 손상시키는지는 무시하고 지나쳐버린다.

23p : 컴퓨터화된 거의 모든 장치와 서비스들은 수동식 제품에 비해 더 많은 기능과 옵션을 보유하고 있다. 그러나, 실제로 우리는 반도체 칩 기술에 의해 동작되는 현대적인 장치들보다 수동식 장치들을 더 잘 이해할 뿐 아니라, 더 융통성 있고 정교하게 활용한다. 첨단 기술 회사들은 제품을 개선한답시고 그저 복잡하고 불필요한 기능들만 제품에 추가하고 있다. 공급자들이 이렇게 행동할 수밖에 없는 이유는 잘못된 개발 과정은 나쁜 제품의 문제를 해결할 수 없고 그저 새로운 기능만 추가할 수 있기 때문이다. 

36p : 첨단 기술 산업계는 깊은 생각 없이 프로그래머들과 엔지니어들을 책임자로 임명했고, 결과적으로 사용 편의성과 거리가 먼 그들의 공학적 문화가 주류를 이루고 있다. 겉으로 보이는 모습과는 달리, 첨단 기술 산업계를 통제하는 사람은 기업의 임원들이 아니다. 주도권을 쥔 사람은 바로 엔지니어들이다. 우리는 반도체 칩이 가능케 한 수많은 혜택들을 서둘러 받아들이는 과정에서 우리의 책임을 남에게 넘겨버렸다. 우리는 정신병자들이 정신병원을 운영하게 만든 것이다. 정신병자들이 정신병원을 운영하게 되면, 그들은 자신들을 괴롭히는 문제의 본질을 명확하게 보지 못한다. 소프트웨어 기반 제품의 개발자들이 자기 손으로 만든 제품을 검토할 때는 그 제품이 얼마나 나쁜지 잘 발견하지 못한다. 그 제품이 얼마나 끔찍하게 사용하기 어렵고 그것을 익히기 위해 얼마나 많은 시간을 허비해야 하는지, 또 그 제품이 매일 그것을 사용해야 하는 사람들을 얼마나 초라하게 만들고 품위를 손상시키는지는 무시하고 지나쳐버린다. 

37p : 우수한 프로그래머가 되기 위해서는 컴퓨터의 속성과 요구 사항을 공감하고 있어야 한다. 그러나 컴퓨터의 속성과 요구 사항은 궁극적으로 컴퓨터를 사용하는 사람들의 속성과 요구사항과 전혀 다르다. 소프트웨어 개발은 고도의 지적 능력을 요구하는 매우 힘든 작업으로, 프로그래머들은 그들에게도 이질적인 사고 과정에 완전히 몰입해야 한다. 프로그래머들의 마음속에서는 프로그래밍 과정의 요구가 외부 세계 사용자들의 어떤 요구보다 우선할 뿐 아니라, 두 세계의 언어들 자체가 서로 어울리지 못한다. 프로그래밍 과정은 프로그래머의 목표와 사용자의 목표가 근본적으로 다르다는 그 이유만으로도 사용하기 쉬운 제품을 만드는 과정을 봉쇄한다. 프로그래머들은 개발 과정이 쉽고 원활하게 진행되기를 바란다. 

41p : 문제가 있다는 것을 아는 것과 문제에 대한 해결책을 찾아내는 것은 전혀 다른 문제이다. 

42p : 인지적 마찰 --> 문제가 바뀔 때마다 변화하는 복잡한 규칙 체계를 대할 때 인간의 사고 체계에서 발생하는 저항감이다. 소프트웨어와 인터랙션은 바로 이 인지적 마찰이 매우 높다. 반면, 물리적인 장치들과의 인터랙션은 아무리 복잡한 장치라 해도 인지적 마찰이 낮은 경향을 보이는데, 이는 기계적인 장치들은 받아들이는 입력이 제한되어 있을 뿐 아니라 상태 변화의 범위도 그만큼 좁기 때문이다. 

43p : 인지적 마찰은 소량인 경우 반드시 나쁘다고 할 수 없으나 누적되기 시작하면 부정적인 효과가 급격하게 증가한다. 

46p : 엔지니어들이 지배하는 기술 세계에서는, 제품의 내부적인 프로그램 디자인이 먼저 이루어지고 최종 사용자의 편의를 위한 인터랙션 디자인은 사후에, 남는 시간에나 수행하는 것으로 취급되어 왔다. 이 책의 목적 중 하나는 이러한 우선 순위를 역전시켜서 소프트웨어 기반 제품을 제작할 때 인터랙션 디자인을 최우선적으로 고려함으로써 얻을 수 있는 이득이 무엇인지 밝히는 것이다. 

47p : 우수한 디자인과 부실한 디자인의 차이는 사용되는 도구나 장치의 종류가 아니라 디자인의 동기이다. 진정한 인터랙션 디자이너는 사용자가 달성하고자 하는 목표가 무엇인가를 바탕으로 자신의 결정을 내린다. 가짜 디자이너들은 다른 여러 가지 하찮은 논리들을 근거로 결정을 내린다. 여기에는 개인적인 선호도, 친숙함, 모르는 것에 대한 두려움, 마이크로소프트사의 지시사항, 동료의 실수 등이 놀라울 정도로 큰 역할을 한다. 하지만, 대부분의 경우 그들의 결정은 무엇이 가장 만들기 쉬운가에 기반을 두고 있다. 

48p : 나는 '인터페이스 디자인'보다는 '인터랙션 디자인'이라는 용어를 선호한다. '인터페이스'는 이쪽에는 코드, 저쪽에는 사람, 중간에 둘 사이에서 메시지를 전달하는 인터페이스가 있는 상태를 암시하기 때문이다. 이는 인터페이스만이 사용자의 요구를 충족시킬 책임을 진다는 것을 암시한다. 인터페이스 수준에서 디자인을 고립시키면 프로그래머에게 "프로그램을 완성한 후에 '인터페이스'가 덧붙여지는 것이므로, 자신이 원하는 대로 코드를 작성할 수 있다"고 주장할 권한을 주는 꼴이 된다. 결국 프로그래밍이 끝난 이후로 디자인이 연기되며, 이는 이미 늦은 것이다. 

55p : 대부분의 소프트웨어 공급자들은 프로그램을 사용하기 쉽게 만드는 방법은 모르지만 기능을 추가하는 법은 확실히 알고 있다. 그래서 늘 그렇게 자기가 할 줄 아는 일만 하는 것이다. 

56p : 기계에 물리적인 컨트롤을 추가하는 것은 여전히 제조 원가라는 부정적인 피드백 루프의 지배를 받지만, 소프트웨어에 기능과 특성을 추가하는 과정은 그렇지 않다. 소프트웨어 제작자들은 기능을 추가하는 것을 거의 공짜로 여기고, 제안되는 신기능은 별다른 반증이 나타나기 전까지는 무조건 훌륭한 투자로 간주한다. 통제자가 없는 상태에서 제품은 순식간에 불필요한 기능들로 채워지고, 이런 제품은 사용자에게 복잡함과 혼란스러움 그 자체일 뿐이다. 

58p : 산업화 시대의 기계는 조작하기 어려운 만큼 그에 비례하여 유용하고 쓸모가 있었지만, 정보화 시대에는 이러한 관계가 성립하지 않으며 유용성이 커지는 것보다 더 빠른 속도로 조작의 어려움이 증가한다. 

79p : 경영자들은 회사에서 어떻게 SW출시 날짜를 정하든 프로그래머들이 설정된 기한을 맞추지 못하리라는 것을 너무나 잘 알고 있다. 개발자들은 압력이 가해질 때 최고의 능률로 일하며, 경영자들은 납품 기일을 압력의 도구로 이용하고 있다. 

82p : 출시지연이 반드시 제품에 치명적인 것은 아니다. 출시가 늦어진 3류 제품은 대체로 실패하겠지만, 사용자에게 가치를 제공하는 제품이라면 계획보다 늦게 출시되더라도 부정적인 영향은 그리 오래 가지 않는다. 대 히트 제품이라면 출시가 1개월 또는 1년이 늦는다 해도 별로 큰 문제가 아니다. 반대로, 제품이 형편없다면 제때에 출시되었다고 누가 관심이나 갖겠는가? 

84p : 어떤 결정적인 기능이 데드라인을 넘기는 요인으로 제외되면, 그 댓가로 십여 개의 다른 하찮은 기능들이 별 반발없이 리스트에 슬쩍 추가되는, 너무나 계산적인 윈-윈 전략이 오고간다. 싸움에서 적당히 지는 것이 필수적인 성공 전략인 것이다. 

85p : 높은 지위에서 높은 연봉을 받는 임원들이 하는 온갖 분석 작업과 신중한 판단은 자기 생각을 관철시키고 영역을 방어하려드는 프로그래머들이 스스로의 구미에 맞는 기능만 골라내는 이러한 행위 때문에 아무 의미가 없어진다. 

86p : 역설적으로 들리겠지만, 사용자들은 사실 기능에 크게 좌우되지 않는다. 여러제품들의 성공과 실패 사례를 통해 사용자들은 기능을 그다지 중요히하지 않는다는 사실이 드러났다. 사용자들은 오로지 자신들의 목표를 이루는 데에만 관심이 있다. 

86p : 내가 꼽는 기능의 유일한 장점은 정량적이라는 것이다. 그리고, 그 셀 수 있다는 특성은 이들이 실제로는 갖고 있지 않은 가치를 가진듯한 느낌을 준다. 기능은 긍정적인 특성이 강하면 강할수록 그만큼 부정적인 면을 갖고 있다. 이들이 유발하는 가장 큰 디자인 문제는 '유용할지도 모르는' 온갖 기능들에 정말로 유용한 소수의 기능들이 뭍혀 버린다는 것이다. 물론, 기능을 구현하려면 돈이 든다. 또, 기능들은 제품의 크기와 복잡도를 증가시킨다. 기능을 추가하면 설명서와 온라인 도움말 기능을 좀더 자세하게 많이 만들어야 한다. 무엇보다도 비용 측면에서, 기능들에 대한 고객의 질문에 응답할 수 있도록 훈련된 고객 센터의 기술 지원 인력이 추가로 필요하다. 

89p : 객관적이고 정량적인 측정은 프로그래머들이나 사업가들 모두에게 매우 중요시된다. 이 측정치들이 성공적인 제품을 생산하는 데 대체로 의미가 없다는 사실은 혼잡한 개발 과정에서 슬그머니 잊혀져 버린다. 

94p : 비싼 월급을 받는 프로그래머들이 멍하니 앉아서 디자인이 완성되기만을 기다리고 있는 꼴을 보고 있노라면 경영자는 거의 미칠 지경이 된다. 프로그래머들이 프로그래밍할 시간에 이들을 그냥 놀리는 것은 어리석은 일이라고 경영자들은 생각한다. 그러나, 디자인이 완성되기 전에 프로그래머들을 투입하는 것은 전혀 경제적인 행동이 아니다. 코딩 과정이 시작된 후에는 프로그래밍의 관성을 중단시키는 것이 불가능해지고, 이제 전과 반대로 디자인 과정이 프로그래머들의 요구에 반응해야만 한다. 장기적으로 볼 때, 프로그래머들에게 아무 일도 시키지 않는 것보다 잘못된 프로그램을 작성하게 하는 것이 더 많은 비용이 든다. 

96p : 모든 반도체 기반 제품의 개발자들은 제품 사용자의 가장 중요한 목표가 무엇인지 파악하고 한치의 흔들림도 없이 이를 달성하는 데에만 초점을 맞추어야 한다. 첨단 기술 산업계의 수많은 가능성들에 속아 넘어가서 정작 중요한 기회를 날려버리는 일은 너무나 흔하다. 프로그래머의 지적수준이나 사업적 통찰력, 성실성, 선의 등과는 전혀 별개로, 프로그래머가 약간만 잘못된 방향으로 가게 되도 회사 전체를 바람직한 사업 영역에서 멀어지게 만들 수 있다. 

103p : 오로지 데드라인이나 기능 리스트의 관점에서만 개발 프로젝트의 범위를 정의한다면, 제품이 제때 출시된다 해도 원하는 결과를 얻지 못할 것이다. 대신, 품질과 사용자 만족의 관점에서 프로젝트를 정의한다면, 사용자가 원하는 제품을 만들게 될 것이고 시간이 더 오래 걸리지도 않을 것이다. 

118p : 사람들은 적당히 속일 수 있고 술수가 통하기도 하는 시스템을 선호한다. 그들은 게임을 완전히 뒤엎을 정도는 아니어도 결과에 약간 긍정적인 영향을 줄 수 있을 만큼 핀볼 기계를 흔들고 싶어한다. 이런 점 때문에 수동식 시스템이 컴퓨터화된 시스템에 비하여 속도는 느리지만 훨씬 더 잘 동작한다. 

119p : 확인용 대화상자는 가장 흔히 볼 수 있는 잘못된 디자인의 예 중 하나이다. 우리가 어떤 행동을 취하려는 것이 '확실한지' 물어보는 대화상자 말이다. 사용자가 '모두 삭제' 명령을 내리면 컴퓨터가 이를 실행하기 전에, 프로그램에서 사용자에게 삭제 명령을 다시 한번 확인하는 대화상자를 띄우는 것이다. 이 모두가 너무나 논리적이지만, 동시에 너무나 잘못되어 있다. 확인용 대화상자는 프로그래머에게 편리한 해결책이다. 이 대화상자 덕분에 프로그래머는 의도하지 않았던 삭제를 직접 수행한 주체로서의 책임을 회피할 수 있기 때문이다. 그러나, 이는 진짜 문제가 무엇인지 잘못 이해하고 있는 것이다. 삭제는 사용자의 책임이며, 그는 이미 명령을 내려버렸다. 인간은 대개 컴퓨터와 같은 방식으로 의사결정을 하지 않으며, 마음을 바꾸거나 자기가 이전에 내린 결정을 취소하고 싶어하는 것은 지극히 정상적이고 흔한 일이다. 컴퓨터 밖의 실제 세상에서는 대부분의 행동들이 연기되거나, 변경되거나, 번복될 수 있다. 이러한 일들이 소프트웨어 기반 제품에서는 불가능할 이유가 없다. 다만 제품을 만드는 프로그래머들이 그렇게 생각하지 않을 따름이다. 

121p : 컴퓨터 세계에 입문하는 초보자들은 소프트웨어가 그렇게 행동하는 데는 어떤 합당한 이유가 있을 것이라고 생각한다. 그렇기는 커녕, 소프트웨어의 행동방식은 수년간 아무 생각 없이 전해져 내려 온 변덕 또는 우연의 결과이다. 

124p : 프로그래머들은 제품에 기능과 특성을 추가하고 싶어한다. 그들은 프로그램의 내부 동작이 아주 효율적으로 이루어지도록 만드는 데에서 창조적인 욕구를 느낀다. 이는 기능적 가능성의 표현이며, 어떤 기술자들은 잘 팔리는 제품을 한번도 출시해보지 못하고서도 행복해할 수 있다. 그들을 고용한 회사가 망하면 그냥 직장을 옮기기만 하면 된다. 그들의 개인적인 성공과 회사의 성공은 서로 무관하다. 

124p : 사업가들은 시장 점유율을 확보하고 제품을 많이 판매하고 싶어한다. 그들은 사람들에게 제품을 구매하도록 동기유발을 시키는 데서 의욕을 느낀다. 이는 실리적 가능성의 표현이며, 어떤 사업가들은 기술적으로 세련된 제품을 출시해보지 않고서도 행복해 할 수 있다. 대부분의 사업가들은 많이만 팔 수 있다면 엉성한 일회용 게임을 팔아도 충분히 만족할 것이다. 

125p : Desirablity --> 이것은 디자이너가 제공하는 것이다. 그들은 "무엇이 바람직한가, 사람들이 무엇을 원하는가?"라고 질문해야 한다. 디자이너들은 무엇이 사람들을 만족시키고 행복하게 하는지 알아야 한다. 제품은 이를 실제로 사용해야 하는 사람들에게 강력한 힘과 즐거움을 주지 못하면 장기적으로 성공할 수 없다. 

127p : 사람은 단기적으로 봤을 때 필요에 의해 크게 좌지우지될 수 있지만, 장기적으로는 원하고 바라는 것이 더 깊고 강렬한 영향을 끼친다. 사람의 욕구는 언제나 필요가 충족된 후에야 드러나는 법이다. 사람은 무언가를 필요로 하면 그것을 얻기 위해 필요한 일을 하지만, 어떤 것을 욕구할 때는 '그것에 충성하게 된다.' 그는 충동 구매라는 것을 알면서도 자신을 행복하게 해주는 그것을 구입할 것이며, 이 때 반드시 논리적으로 판단하지는 않을 것이다. 소비자가 어떤 제품이나 브랜드를 욕구할 때, 그의 충성도는 회사를 이끌어나가는 가장 강력한 힘 중 하나가 된다. 

145p : 인터랙션 디자인방법을 배우지 않은 사람은 자신이 사용자라고 상상하면서 자신을 기준으로 디자인하는 경향이 있는데, 프로그래머들은 자연히 이 함정에 빠지게 된다. 자신을 기준으로 디자인 하는 사람들로 이루어진 그룹은 디자인 결과를 얻어내는데 엄청난 고생을 하게 마련이다. 왜냐하면, 이들 사이에는 사용자에 대한 분명하고 공통된 의견이 존재하지 않아서 논의 과정이 끝없이 늘어지기 때문이다. 

157p : 고도로 엔지니어화된 사람들의 일곱가지 습관 1) 자신의 이기적인 면에 관대하다. 2) 장님이 되어야 시력이 좋아진다. 3) 먹이를 주는 손을 물 뿐 아니라 자기 손도 문다. 4) 자신의 이미지를 유지하기 위해 열심히 노력하느라 이미지 자체에는 신경을 쓰지 않는다. 5) 고장나지 않은 것을 고장 날 때까지 고친다. 6) "내가 잘못 답한 것이 아니라, 당신이 잘못된 질문을 한 것입니다." 7) 비판이 없으면 칭찬으로 생각한다. 

179p : 엔지니어들은 자기들 마음대로 사용자 요구보다 프로그래밍 효율성에 더 큰 가치를 둔다. 

179p : 우리가 인터랙션하는 소프트웨어에는 그전부터 있었던 것이라는 이유 하나만으로 존재하는 요소들이 아주 많다. 

183p : 프로그래머들은 인터랙션 디자이너들이 정밀하게 렌더링한 스크린샷을 가져가서는 이를 인터페이스에 대한 막연한 제안쯤으로 취급한다. 그들은 디자이너가 작성한 기능과 feature list를 가져가서는 자신들이 개인적으로 동의하는 항목이나 특히 만들기 쉬운 항목들만을 골라낸다. 

189p : (MS의 Explorapedia의 개발중...) 기능들을 자꾸 더하는 것이 디자이너가 맡은 일이었고, 데드라인을 맞추기 위해 여기에 반대하는 것이 개발자의 역할이었고, 심사숙고한 후 판결을 내리는 것이 프로그램 매니저의 업무였다. 이렇게 적대적인 관계는 반드시 고통스러운 대가를 치르게 마련이다. 사람, 제품, 또는 회사가 손해를 보게 되어있다. 

190p : 마이크로소프트의 디자이너와 SW개발자 집단간의 이질성에 대한 얘기 --> 최근 상황이 조금 나아지기는 했지만, 두 집단은 근본적으로 다른 언어로 말했으며 정반대의 지적, 문화적, 심리적, 미적 배경을 갖고 컴퓨터의 세계에 발을 들여 놓았다. 디자이너들은 예술계 출신으로서 마이크로소프트에 들어왔고, 개발자들은 수학과 과학의 세계에서 왔다. 개발자들은 디자이너들의 생각이 모호하고 체계적이지 않으며 취향이 멋대로라고 생각했기 때문에 그들을 깔보았다. 디자이너들은 개발자들이 상상력이 없고 보수적이며 그들의 디자인을 구현하려는 방법을 찾아보지도 않고 곧바로 거부해버린다고 느꼈다. 디자이너들은 프로그래밍을 이해할 수 없었으므로, 개발자들이 디자이너들의 디자인이 프로그램 불가능하다고 주장해도 그것이 사실인지 아닌지를 평가할 방법이 없었다. 

191p : 성공의 근본적인 이유 대신 성공의 외형만을 모방하는 것은 흔히 있는 실수이다. 

199p : 놀랍게도, 컴퓨터가 수년 전에 비해 전반적으로 훨씬 더 강력하고 싸고 빠르다는 단순하고 분명한 사실이 소프트웨어 개발에 실질적으로 반영되지 않고 있다. 그 결과, 대부분의 소프트웨어 제품들이 사용자를 위해 그다지 열심히 일하지 않는다. 대신, 그것들은 CPU에 과부하가 걸리고 있다는 잘못된 인식으로 CPU를 보호하는 데만 급급하다. 결과적으로, 소프트웨어 기반 제품들은 인간 사용자에게만 과도하게 일을 시키는 경향이 있다. 디자인 전문가인 빌 모그리지는 이러한 태도가 "반도체에 친절하고 사용자에 가혹하다"고 표현한다. 

200p : 개발자들은 스스로에게 "시스템에 맞게 만들 수 있을까, 이 제품이 충분히 빠르게 반응할까, 제품을 보다 효율적으로 만들기 위해서 필수적이지 않은 것 중 무엇을 버릴까?"등을 묻는 것이 몸에 배여 있다. 그 때문에 다음과 같은 더 적절한 질문들이 고려대상에서 제외된다. "사용자들이 이것을 이해할까, 이 정보를 상식적으로 이해 가능한 방식으로 제공할 수 있을까, 명령 순서가 사용자가 원하는 내용에 적절할까, 사용자는 어떤 정보를 가장 필요로 할까?" 

207p : 크라이슬러 자동차의 회장인 로버트 루츠는 조사 대상 집단의 80%에 달하는 사람들이 새로운 Dodge Ram 픽업트럭을 싫어했다고 말한다. 그는 나머지 20%의 사람들이 그것을 아주 맘에 들어 했기 때문에 생산을 진행시켰고 이 제품을 베스트셀러로 만들었다. 비록 소수일지라도 사람들이 당신 제품을 좋아하고 아끼게 만드는 것이 바로 성공의 비결이다. 반직관적으로 들릴 수 있지만, 단 한 사람의 사용자를 위해 디자인 하는 것이 많은 사람들을 만족시키기 위한 가장 효과적인 방법이다. 

215p : 프로그래밍은 패러다임의 극단에 있는 경우들에 의해 정의되는 반면, 디자인은 패러다임의 중심에서 정의된다. 

224p : 흔한 실수 중 하나가 실제 사용자가 아니라 제품 관련자를 위해 디자인하는 것이다. 많은 IT잡지에 실린 그 제품에 대한 리뷰는 제품 사용자보다는 리뷰를 쓸 작가들을 위해 디자인된다. IT 사업 분야에서는, 제품을 구매하는 IT 매니저가 실제로 그것을 사용하는 사람이 아닌 경우가 많이 있다. 

243p : 사람들을 행복하게 하는 소프트웨어 기반 제품을 디자인하려면, 과연 이 사람들이 어떤 사람들인지 정밀하게 알고 있어야 한다. 

262p : 새로운 기술을 활용하는 것이 소프트웨어 회사의 '업무'일지는 모르나 사용자의 '목표'는 결코 아니다. 

276p : 내가 컴퓨터에게 파일을 삭제하라고 이야기 할 때는, 컴퓨터가 내게 "확실합니까?"라고 되묻는 것을 원하지 않는다. 당연히 확실하지 않은가. 확실하지 않으면 삭제하라고 하지도 않았을 것이다. 나는 컴퓨터가 자신의 판단에 대해 용기를 갖고 일을 진행하여 파일을 삭제하기를 원하는 것이다. 반면, 컴퓨터가 내가 잘못했을 지도 모른다는 의심을 약간이라도 갖게 된다면 내가 마음을 바꿀 것을 예측하여 그 파일을 복구시킬 준비를 해놓아야 한다. 어느 경우이건, 제품은 자신의 동작에 대한 확신을 갖고 있어야 하며 자기 책임을 회피하고 불평을 늘어 놓으면서 내게 모든 걸 떠넘기려고 해서는 안된다. 

296p : 효과적인 시나리오는 그 깊이보다는 너비 면에서 완성도가 더 높아야 한다. 즉, 시나리오가 처음부터 끝까지 기술되는 것이 시나리오의 각 단계가 아주 세세하게 묘사되는 것보다 더 중요하다. 중요한 것은, 우리의 디자인 노력에 도움을 주는 시나리오만 개발하고 극단적인 경우들 속에서 헤매지 않는 것이다. 

299p : 필수적이지도 않고 자주 수행되지도 않는 업무들은 한 마디로 정성을 들여 디자인을 할 필요가 없다. 

302p : 사람들은 적당한 수준의 경험과 능력을 획득하게 되면 대개 그 수준에 영원히 머무르게 된다. 특히 높은 인지적 마찰을 유발하는 제품의 경우, 사용자는 그것에 대해 배우는 데서 아무런 기쁨을 얻지 못한다. 그래서 그들은 최소한 필요한 것만 익히고 나면 바로 배움을 중단한다. 

308p : 전형적인 엔지니어링 과정은 제약 조건과 한계들을 읊어대는 것으로 시작한다. '우리가 할 수 없는' 것들에 대한 문답이 너무나 자주, 강력하게 천명되기 때문에 그 진실 여부와는 관계없이 거의 교리처럼 되어 버린다. 인터랙션 디자이너들은 무엇을 할 수 없다는 모든 가정들에 대해 응당한 의구심을 갖고 있어야 한다. 종종, 우리는 그 가정을 액면 그대로 받아들이기를 거부하는 것만으로도 그런 가정된 한계들을 우회하는 방법을 발견하곤 한다. 

328p : 사용자가 화면에서 보는 것이 더 적을수록 디자이너가 일을 더 잘한 것이다. 

329p : 적은 것을 가지고 많은 일을 하는 것이 언제나 더 나은 것이다. 

330p : 정말로 획기적인 개념적인 진보는 대부분 그 일이 있기 전에는 전혀 예측 불가능해도 지나고 나면 너무나 분명하게 보이는 법이다. 디자인에서 혁신을 꾀하는 것은 정말로 어려운 일이다. 

335p : (기존 SW 개발방식) 프로그래밍 >> 버그테스트, 사용자테스트 >> SW 개선 

           (올바른 SW 개발방식) 디자인 >> 프로그래밍 >> 버그테스트, 사용자테스트 >> SW 개선 

337p : 내게는 현재의 사용성평가 방법론이 사포와 같은 것으로 여겨진다. 당신이 의자를 만든다면, 사포가 그것을 매끄럽게 만들 수 있다. 당신이 탁자를 만든다면, 사포가 그것도 매끄럽게 만들 수 있다. 그러나 사포질을 아무리 많이 한다해도 탁자를 의자로 바꿀 수는 없다. 그러나, 수천 명의 사람들이 별 생각없이 그들의 사용성 능력을 사포 삼아 그들의 탁자를 의자로 만들기 위해 열심히 닦아대는 것을 보아 왔다. 

338p : 사용성평가가 가장 큰 공험을 하는 때는 프로그래머들을 실험실의 일방 투시 거울 뒤에 앉히고 전형적인 사용자들이 그들의 프로그램과 씨름하는 모습을 보여줄 때일 것이다. 프로그래머들은 "당신들, 정신 박약아를 상대로 테스트하고 있는 거죠?"와 같은 말을 들으면서 심한 충격을 받고 눈앞의 현실을 믿으려 하지 않을 것이다. 사용성 테스트는 고집 센 소프트웨어 엔지니어의 뺨을 때리는 상당히 유용한 충격 요법으로, 정말로 문제가 있다는 것을 그들에게 직접 보여줄 수 있다. 이 방법은 같은 목적으로 관리자에게도 사용할 수 있다. 

346p : 포커스 그룹 인터뷰는 몇 가지 제품 군에서 효과적일 수 있지만, 고도의 인지적 마찰이 존재하는 제품에 대한 신뢰할 만한 평가 수단으로서 포커스 그룹 인터뷰에 의지하는 것은 분명 실수이다. 

350p : 마이크로소프트사는 음성 인식과 필기체 인식을 완성시킬 수만 있으면 인터페이스가 사용하기 쉬워질 것이라고 말한다. 내 생각엔 정말 어이 없는 얘기이다. 새로운 기술은 하나같이 더 빠르고 강력한 시스템으로 사용자를 좌절시킬 가능성만 높여줄 뿐이다. 더 나은 인터랙션으로 가는 열쇠는 컴퓨터와 사용자 사이의 불확실성을 감소시키는 것이다. 

357p : 고객의 이야기를 듣는 것과 고객을 따르는 것은 전혀 다른 것이다. 듣는 것은 괜찮다. 그것은 당신이 들은 내용을 당신만의 필터로 걸러낸다는 의미를 담고 있다. 따르는 것은 나쁘다. 그것은 그저 고객이 요구하는 것을 그대로 수행하는 것을 뜻한다. 

358p : 고객 중심적인 제품들에는 일관성 있는 디자인이 없다. 그것들에는 프로그램에 대한 한결같은 비전이 결여되어 있다. 개념적 완전성이 없으면 다음 2가지 일이 발생한다. 1) 고객들이 당신 제품의 디자인을 좌지우지하고, 2) 당신은 당신 제품의 디자인을 통제하고 결정하는 권한을 포기하게 된다. 고객들이 아무리 좋은 의도를 갖고 있다 해도, 그들에게는 당신의 제품을 하나의 단일한, 개념적인 통일체로 생각할 능력이 없다. 

359p : 고객들은 당신에게 서로 상반되는 주문들을 마구 해대면서, 그 중 어떤 것이 따라야 하는 올바른 주문인지 당신이 판단해줄 것을 기대한다. 당신이 고객 중심적으로 일한다면, 당신의 제품은 체계적인 순서로 성장하는 대신 매 버전마다 새롭게 변신하게 된다. 제품은 결국 서로 어울리지 않는 요소들과 아무렇게나 끼워 넣은 기능들로 가득 차게 되고, 제품 개발자 존 지커의 표현을 빌면 '개밥'이 되고 말 것이다. 

363p : 디자인과 프로그래밍을 동시에 수행하면 당신이 얻는 것은 오직 프로그래밍뿐이다. 

369p : 인터랙션 디자인 집단도 그들 스스로 2가지 약속을 해야 한다. 첫째, 인터랙션 디자이너들은어느 정도 책임을 질 필요가 있다. 그들은 더 이상 프로그래머들이 제품 성공에 대한 모든 책임을 지게 내버려두면서 방관자적인 자세로 그들에게 충고나 해주는 자세를 버려야 한다. 2번째는 그들의 디자인을 문서화하는 것이다. 

369p : 내가 수 년에 걸쳐 혹독하게 깨달은 교훈 중 하나는 좋은 디자인, 심지어는 위대한 디자인이라 해도 실제로 만들어지지 않으면 아무 의미가 없다는 것이다. 

370p : 디자이너들은 프로그래머들이 그들의 솔루션을 청사진으로 생각하고 실제로 그것을 바탕으로 코드를 작성할 수 있을 정도로 충분한 완성도와 구체성을 갖춘 솔루션을 작성하고 스토리보드로 만들고 애니메이션해보고 스케치해야 한다. 개발자들에게 그 솔루션이 구현가능할 정도로 탄탄하고 확실하다는 확신을 심어주려면 충분히 다양한 상황들에 대해서도 자세히 묘사해야 한다. 

370p : "서류에 쓰여 있지 않으면 존재하지 않는 것이다."는 현재의 소프트웨어 디자인 세계에 가장 정확히 들어맞는 말이다. 문서화되지 않은 것은 잘못 해석되거나 무시될 가능성이 매우 높다. 이는 프로그래머들의 동기가 사용자들의 동기와 아주 많이 다르기 때문이다. 

379p : 이 책에서 충고하는 가장 중요한 포인트는 인터랙션 디자이너들이 제품 품질의 궁극적인 책임자여야 한다는 것이다. 인터랙션 디자이너는 프로그램의 내용과 행동을 결정할 수 있어야 한다. 그는 기능 목록과 대부분의 스케줄을 관장해야 한다. 그는 사용자의 대변인어야 하며 제품의 모든 외적인 측면들을 통제할 권한을 가져야 한다. 

395p : 컴퓨터 소프트웨어는 말 그대로 소프트하기 때문에, 만드는 사람이 원하는 대로 어떤 형태로든 만들어 질 수 있다. 그들이 소프트웨어를 사용하기 쉽게 만들지 않는 것은 그것이 불가능해서가 아니라 그들이 그 방법을 모르기 때문이다. 그들은 이 부끄러운 사실을 인정하는 대신 '기술적인 이유' 때문에 할 수 없는 것이라고 주장한다. 

398p : 소프트웨어 개발 주기에 관한 최근의 학설은 테스터와 코더의 1대1 비율이 적절하다고 주장한다.