| 정신병원에서 뛰쳐나온 디자인 | |||||
|---|---|---|---|---|---|
![]() |
| ||||
p.372 ohyecloudy 인터랙션 디자이너는 어떻게 만드는가에 관한 세부적인 사항들은 애써 피해가는 반면 무엇을 만들고 무엇을 만들지 않아야 하는지 결정하는 데는 많은 영향을 끼치기 때문에, 우리는 디자인을 일종의 프로젝트 정의 과정이라고 본다. 본질적으로, 인터랙션 디자이너들은 제품의 외부를 묘사함으로써 제품의 내부를 결정한다. 즉, 구현 문제는 프로그래머들에게 맡겨두면서도 사용자와의 인터랙션은 아주 자세하고 세밀하게 명세한다. 2007-12-30 (0) |
p.372 ohyecloudy 많은 사람들이 인터랙션 디자이너가 하는 일, 그리고 인터랙션 디자이너에 의해 이루어져야 하는 일이 사용자 인터페이스 디자인이라는 잘못된 생각을 갖고 있다. 인터페이스 디자인이 디자이너에 의해 수행되어야 하는 일 중 하나인 것은 분명 맞지만, 소매로 판매할 때의 포장작업처럼 디자인 과정에서 단지 보조적인 역활을 할 뿐이다. 2007-12-30 (0) |
p.306 ohyecloudy 용어가 불충분하거나 용어들이 정확하게 정의되지 않으면, 사람들의 사고가 더 보수적으로 변한다. 완전하고 정밀한 일련의 용어 집합 없이는 새로운 아이디어들을 효과적으로 주장하고 지지할 수 없으며, 따라서 이들은 너무 빨리 폐기될 수밖에 없다. 우리가 선택한 용어들은 제품 상자의 겉면을 치장할 단어들이 아니다. 우리는 우리의 어휘들을 내부적으로만 사용하며, 마케팅 부서에서 이 용어들을 마음에 들어 하는지에 관해서는 신경 쓰지 않는다. 어휘들은 오로지 정밀하기만 하면 된다. 나중에, 마케팅 부서에서 구매 대중을 대상으로 사용할 만한 적절한 단어들을 생각해 낼 것이다. 2007-12-30 (0) |
p.300 ohyecloudy 프로그램이 많은 기능들을 제공해야 하긴 하지만, 그 기능들 전부가 어디서나, 모든 사용자들에게, 항상 필요한 것은 아니다. 어떤 사용 시나리오든, 사용자 페르소나는 컨트롤과 데이터의 아주 작은 일부분 외에는 사용할 필요가 없을 것이다. 하지만 그것이 어떤 컨트롤과 데이터인가는 시간에 따라, 어떤 문제를 검토하느냐에 따라 바뀔 수는 있다. 인터페이스는 일상적인 사용 시나리오에서 요구하는 컨트롤과 데이터는 인터페이스에서 눈에 잘 띄는 곳에 배치하고 나머지는 전부 부수적인 위치로 옮김으로써, 인터페이스는 엄청나게 간단해질 수 있다. 2007-12-30 (0) |
p.279 ohyecloudy 역설적이게도, 컴퓨터 시스템이 강요하는 엄격한 규칙들 중 대부분이 바로 이러한 실수들을 예방하기 위해 실시되는 것이다. 이 유연하지 못한 규칙들은 인간과 소프트웨어들을 서로 적으로 만들며, 인간은 큰 실수를 막는다는 이유로 조작을 금지 당했기 때문에 곧 소프트웨어에 정말로 심각한 문제가 생기지 않도록 보호하는데 더 이상 신경을 쓰지 않게 된다. 유연하지 못한 규칙들을 유연한 인간에게 강제하면, 양쪽 모두가 실패하기 마련이다. 2007-12-30 (0) |
p.269 ohyecloudy 대부분의 소프트웨어는 그 제품을 사용하는 사람이 누구인지 모르며 알려고 하지도 않는다. 그것이 항상 나에 의해서만 독점적으로, 끊임없이, 반복적으로 사용되고 다른 누구에 의해서도 사용되지 않음에도 불구하고 말이다. 2007-12-29 (0) |
p.217 ohyecloudy 2.3명의 자녀를 둔 우리의 부모는 절대 구체적일 수가 없다. 만약 그들이 구체적이라면 그런 불가능한 평균값은 가질 수 없기 때문이다. 평균적인 페르소나는 정밀한 페르소나의 특수성이 갖는 이점을 가질 수 없다. 페르소나들의 강력한 힘은 그들의 정밀성과 특수성이다. 그들을 집단적으로 취급하는 것은 그 힘을 약화시키게 된다. 2007-12-29 (0) |
p.222 ohyecloudy 진보한 프로그래머 - 로즈메리가 이것을 프린트하고 싶어할까요? 즐거운 인터랙션 디자이너 - 아니오. 하지만 제이콥은 분기별로 프린트된 리포트를 원할 수도 있어요. 진보한 프로그래머 - 좋아요. 그렇게 거의 필요하지 않은 경우라면, 괜히 우리가 직접 화려한 리포트-작성 기능을 만들 필요없이 돈으로 살 수 있는 도구를 하나 정해 라이센스를 받는 편이 우리의 시간과 노력을 절약할 수 있겠군요. 즐거운 관리자 - 그러면 출시 예정 스케줄을 2주나 앞당길 수 있어요! 2007-12-29 (0) |
p.221 ohyecloudy 프로그래머 - 사용자가 이것을 프린트하고 싶어하면 어떻하죠? 인터랙션 디자이너 - 로즈메리는 프린팅하는 데는 별로 관심이 없습니다. 프로그래머 - 하지만 누군가 프린트하기를 원할 지도 모르잖아요. 인터랙션 디자이너 - 우리는 로즈메리를 위해 디자인하는 것이지 '누군가'를 위해 디자인 하는 것이 아니에요. 2007-12-29 (0) |
p.217 ohyecloudy 페르소나들은 우리가 사용하는 단 한 가지의 가장 강력한 디자인 도구이다. 그들은 이후에 이루어지는 모든 목표-지향적 디자인의 기초가 된다. 페르소나들은 우리에게 디자인 문제의 방향과 본질을 제대로 볼 수 있도록 해준다. 2007-12-29 (0) |
p.185 ohyecloudy 나는 첨단 기술 분야의 임원들이 "프로그래머들이 기능을 완성시킨 후에 디자이너를 투입하겠다"고 말하는 것을 들어 왔다. 그 결과는, 인터랙션 디자이너들이 기여할 수 있는 기회들을 대부분 의미 없게 만들어버리는 것일 뿐이다. 2007-12-29 (0) |
p.182 ohyecloudy 상충되는 이해 관계가 뻔히 눈에 보임에도 불구하고, 우리는 늘 프로그래머들이 개인적인 구현 고려 사항을 바탕으로 디자인 결정을 내리도록 내버려 둔다. 2007-12-29 (0) |
p.119 ohyecloudy 확인용 대화상자는 프로그래머에게 편리한 해결책이다. 이 대화상자 덕분에 프로그래머는 의도하지 않았던 삭제를 직접 수행한 주체로서의 책임을 회피할 수 있기 때문이다. 그러나, 이는 진짜 문제가 무엇인지 잘못 이해하고 있는 것이다. 삭제는 사용자의 책임이며, 그는 이미 명령을 내려버렸다. 프로그램은 망설일 시간이 없다. 주저 없이 요청받은 일을 수행해야 한다. 지금 피하려고 하는 책임은 사용자의 책임이 아니라 사용자가 명령을 내린 것이라 해도 그 명령을 '되돌릴 수 있는' 준비가 되어 있어야 하는 프로그램의 책임임인 것이다. 2007-12-29 (0) |




( 3.5 / 2 )
(



